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Capítulo  I 
Introducción 


Imagínese  trabajando  en  una  gran  empresa.  Miles  de  ordenadores  interconectados  entre  sí. 
Gran  cantidad  de  dalos  circulando  por  la  red.  Acceso  a  múltiples  aplicaciones  que  hacen 
la  vida  más  cómoda.  Salida  hacia  Internet.  Conectividad  con  otras  organizaciones  a  través 
de  ser\^icios  como  el  correo  electrónico.  Comprar  electrónicamente  sin  moverse  del  sitio  o 
ver  la  cuenta  bancaría. 

Lo  real  es  que  uo  hay  que  echar  mucha  imaginación  para  pensar  en  esta  situación,  es  el 
día  a  día  de  muchas  personas.  Sin  embargo  la  base  de  ftincionalidad  de  muchos  de  estos 
elementos  se  íraguaron  hace  mucho  tiempo  en  las  décadas  60  y  70  del  anterior  siglo.  Para 
aquellos  idealistas,  las  situaciones  anteriores  no  eran  n¡  más  ni  menos  que  suposiciones.  En 
la  mayoría  de  las  circunstancias  ni  siquiera  se  podía  atisbar  la  revolución  que  marcarían  las 
bases  que  estaban  asentando. 

Muchos  años  después,  esas  bases  iniciales  y  teóricas,  siguen  actuando  casi  como  fueron 
diseñadas.  Hace  falta  mucho  tiempo  para  cambiar  las  cosas,  máxime  cuando  han  sido 
creadas  con  un  fin  y  adaptadas  según  la  necesidad.  Mírese  sino  el  sistema  de  interconexión 
de  sistemas  abiertos  (OST),  creado  como  '‘el  modelo''  de  red  en  el  año  1984  y  que  debería 
marcar  la  referencia  en  cuanto  a  la  conectividad  entre  sistemas.  Sin  embargo  acabó 
prevaleciendo  el  modelo  TCP/IP  que  ya  se  encontraba  en  explotación,  a  pesar  de  sus 
numerosos  fallos  a  nivel  teórico. 

Sus  bases  sentaron  los  fundamentos  actuales  de  funcionalidad  desde  las  redes  de  área 
local  hasta  la  red  de  redes:  Intemet.  Esto  es  así  tanto  para  las  cosas  buenas  como  para  las 
malas.  Una  evolución  basada  en  la  necesidad  presenta  el  problema  de  que  aunque  resulte 
adaptativo  puede  fallar  en  elementos  tan  significativos  como  el  de  la  seguridad.  Y  es  que 
TCP/IP  tiene  más  en  cuenta  la  funcionalidad  que  otros  posibles  factores.  La  seguridad  ha 
sido  tenida  en  cuenta  posteriormente,  cuando  el  elemento  malicioso  de  la  capa  8,  revela 
los  fallos  existentes,  los  explota  y  demuestra  que  la  seguridad  es  una  parte  muy  importante 
dentro  de  las  comunicaciones. 


10 


Ataques  en  redes  de  datos  IPv4  e  IFv6 


Sin  embargo,  pese  a  su  imporlancia,  la  lentitud  con  la  que  se  desenvuelven  en  ocasiones  los 
acontecimientos,  o  bien  no  ofrecen  la  respuesta  esperada  o  no  se  le  da  la  debida  importancia 
que  requiere.  Quede  aquí  el  ejemplo  de  la  nueva  generación  de  protocolo  de  Internet  IPv6. 
Cuando  se  empieza  a  planificar  la  evolución  natural  motivado  fundamentalmente  por  el 
agotamiento  de  direcciones  posibles,  los  ataques  que  de  diversas  índoles  se  producían  en 
las  redes  eran  ya  un  hecho.  Podría  haberse  diseñado  el  protocolo  intentando  en  la  medida 
de  lo  posible  que  se  paliaran  los  problemas.  Sin  embargo  se  evoluciona  en  cuanto  a  la 
funcionalidad,  se  'hmplementa”  de  fonna  nativa  el  concepto  de  la  seguridad  IP  (ÍPsec)  y  se 
alteran  algunos  conceptos  en  la  relación  del  descubrimiento  de  identidades.  Sin  embargo 
ese  advenimiento  de  IPsec,  no  es  ni  menos  novedoso  y  si  ha  fracasado  por  lo  menos 
parcialmente  en  las  redes  de  área  local  en  lPv4,  por  qué  no  lo  iba  a  hacer  en  IPvó. 

Es  más,  tal  y  como  se  verá  en  páginas  posteriores  IPv6  tendrá  nuevos  vectores  de  ataque 
inexistentes  hasta  la  fecha  y  que  pueden  suponer  un  quebradero  de  cabeza  más  para  los 
administradores  de  red.  Estos,  se  sumaran  a  la  lógica  adaptación  en  cuanto  a  la  electrónica 
de  red,  servicios  y  funcionalidades  del  protocolo  en  sí.  A  pesar  del  número  de  años  que 
“lleva  viniendo”  la  nueva  generación  de  ÍP,  las  personas  son  reacias  al  cambio  (también 
a  aprender  algo  nuevo).  Se  intentará  equiparar  con  IPv4  pero  en  lo  que  concierne  a  su 
funcionalidad  cambia  significativamente  y  por  lo  tanto  lo  que  se  exige  es  un  reaprendizaje 
adaptativo  y  no  una  simple  adaptación.  También  en  el  concepto  de  seguridad,  nuevos 
protocolos,  nuevos  conceptos  y  elementos  de  comunicación  requieren  la  aplicación  de 
nuevas  medidas  o  la  adaptación  de  las  ya  existentes. 

Quizás  una  tecnología  como  lPv6,  llegará  solo  al  infonnático,  al  que  implementa  la  red  o 
los  servicios,  para  el  resto  será  un  puro  trámite  (tecnicismos  de  difícil  apreciación)  más  o 
menos  transparente.  Sin  embargo  un  concepto  importante  en  las  comunicaciones  es  que 
todos  forman  parte  de  ella.  El  que  accede  a  una  red  inalámbrica,  el  que  recupera  un  fichero 
o  el  que  introduce  sus  credenciales  en  la  web  de  moda  hace  uso  de  las  comunicaciones. 
Quizás  desconozca  los  fundamentos  de  IPv6  o  de  IPv4,  estos  no  serán  más  que  números 
más  o  menos  largos,  pero  de  su  seguridad  depende  que  las  cosas  se  hagan  bien. 

Si  alguien  intercepta  su  comunicación,  los  datos  podrían  quedar  en  manos  de  un  desaprensivo 
que  los  utilizaría  váyase  a  saber  con  qué  fin.  La  confidencialidad  de  los  datos  es  algo  latente 
y  a  veces  vox  populi,  por  ejemplo  cuando  a  un  famoso  le  roban  su  cuenta  de  la  red  social  o 
las  fotografías.  Parece  algo  lejano,  porque  ocurre  a  determinadas  personas  por  ser  quienes 
son,  pero  eso  realmente  no  es  así.  Existen  muchos  casos  de  robo  de  cuentas  de  acceso  a 
servicios  web,  credenciales  bancarias  o  ficheros  de  muchas  personas  anónimas,  pero  no 
suelen  transcender,  porque  no  son  mediáticas,  hasta  que  su  número  !o  hace  suficientemente 
significativo  como  en  el  caso  de  Sony  y  el  acceso  a  infonnación  de  la  red  de  Playstation. 
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Cualquier  empresa  o  particular  puede  ser  el  objetivo  de  un  ataque  sin  necesidad  de  ser 
famoso. 

Las  estrategias  de  negocio  de  una  empresa,  los  datos  sensibles  de  productos  investigados  u 
otras  circunstancias,  son  en  la  mayoría  de  las  ocasiones  gestionadas  por  personas  anónimas. 
Cuando  se  habla  de  espionaje  industrial  un  vector  de  ataque  muy  importante  lo  constituye 
la  red.  Fundamentalmente  porque  se  asume  que  la  gente  está  ‘‘protegida”  en  la  red  interna, 
desconoce  lo  que  pasa  y  los  propios  axiomas  de  seguridad  empresariales  tradicionales 
hacen  bajar  la  guardia.  Muchas  personas  no  harían  determinadas  cosas  en  un  cibercafé, 
pero  sí  en  la  red  de  su  empresa.  Principalmente  porque  se  siente  protegidas.  Desconocen 
lo  que  pasa  pero  confian  en  unos  administradores  que  hacen  todo  lo  posible  para  que  todo 
esté  seguro  y  además  en  la  propia  red  de  la  empresa  no  hay  “enemigos".  Sin  embargo 
desconocen  varias  cosas  importantes; 

-  Muchos  de  los  ataques  más  efectivos  se  dan  siempre  desde  dentro,  puesto  que  la 
seguridad  es  más  laxa. 

-  Se  emplean  muy  a  menudo  axiomas  demasiado  antiguos  en  la  protección  de  los 
elementos  para  que  sean  fimcionales,  como  que  el  atacante  fundamental  es  externo  y 
hay  que  protegerse  de  la  amenaza  externa. 

-  Los  sistemas  de  comunicación  son  inseguros  por  defecto. 

-  Muchos  “informáticos”  ni  están  formados,  ni  lo  que  es  peor,  concienciados  con 
los  problemas. 


Si  la  empresa  no  plantea  una  adecuada  estrategia  de  seguridad,  puede  ser  que  un  buen  día  se 
encuentre  con  que  su  investigación  estrella  se  encuentre  en  manos  de  la  competencia,  que 
su  departamento  de  administración  se  ha  expandido  a  ésta  o  que  en  su  red  se  encuentran 
más  sistemas  de  los  que  deberían  existir. 

La  seguridad  es  cosa  de  todos  aunque  algunos  no  lo  quieran  ver  y  digan  que  es  cosa  de 
informáticos.  Cuando  sus  cuentas  corrientes  se  vean  afectadas  por  una  mala  interpretación 
de  lo  que  reviste  el  uso  de  los  certificados,  empezarán  a  creer.  El  ser  humano  es  reactivo  y  la 
mayor  parte  de  las  veces  es  necesario  que  pase  algo  para  que  se  desencadene  la  necesidad. 
Aquel  que  piense  que  nunca  le  ha  pasado  nada,  puede  ser  que  realmente  nunca  le  haya 
pasado  nada  o  bien  que  seguramente  no  ha  sido  consciente  de  que  le  haya  pasado  algo. 

Por  ejemplo  sin  que  le  sea  transmitido  a  una  persona  los  conocimientos  adecuados,  la 
consciencia  del  uso  de  certificados,  pasa  por  “eso  es  algo  que  hace  que  la  página  web  sea 
segura  ¿no?”.  Esta  respuesta  es  una  versión  real  dada  por  un  usuario  donde  tras  unos  test  de 
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ataque  de  hombre  en  medio,  se  le  preguntó  et  por  qué  aceptaba  un  certificado  cuando  había 
Lin  error  en  pantalla  al  acceder  a  la  intranet.  A  la  persona  se  le  comunicó  que  no  debería 
aceptarlo  cuando  fuera  a  la  intranet  de  la  organización*  Sin  embargo  su  respuesta  fue  de  lo 
más  convincente:  “es  que  eso  lo  he  hecho  muchas  veces  y  nunca  ha  pasado  nada.  Además  si 
le  digo  que  no  me  cierra  la  pantalla’’.  Sorpresa,  pero  es  cierto  que  algo  no  se  está  haciendo 
muy  bien*  O  no  se  le  transmite  los  conocimientos  oportunos  o  bien  se  le  deja  aceptar  una 
responsabilidad  para  la  cual  no  está  cualificado* 

Proporcionar  a  alguien  neófito  en  el  uso  de  los  sistemas  infonnáticos  “algo  tan  complejo 
como  una  comunicación  HTTPS  y  el  uso  de  los  sistemas  de  certificados”,  sin  explicar  al 
que  lo  va  a  utilizar  el  por  qué  y  sus  fundamentos,  es  como  darle  un  Formula  1  a  cualquier 
conductor  y  decirle  que  dé  una  vuelta  completa  a  un  circuito  sin  darle  los  mínimos  detalles 
ni  siguiera  de  como  se  pone  en  marcha.  Al  final  las  cosas  se  pueden  hacer  por  instinto,  pero 
difícilmente  se  harán  bien,  porque  el  factor  último  será  el  de  la  comodidad  y  el  de  intentar 
explicar  dentro  de  su  alcance  técnico  el  por  qué  pasa  eso. 

Si  por  ejemplo  una  persona  ve  en  un  acceso  FTTTPS  un  error  y  en  otra  página  no,  y  el 
resultado  es  que  si  acepta  el  error  accede  sin  más,  acabará  aceptando  el  problema  como 
algo  natural.  En  informática  las  cosas  fallan  y  su  solución  es  simple,  como  apagar  y  volver 
a  encender*  Pararse  a  pensar  en  el  problema  no  le  va  a  ayudar  en  nada  porque  seguramente 
no  esté  en  sus  manos  la  solución  (o  si  lo  está,  no  se  le  ha  razonado  ni  explicado).  Al  final 
es  una  dicotomía:  o  sí  o  no,  y  el  no  supone  “que  se  cierre  la  pantalla”*  Además  como  en  el 
acceso  a  muchos  sitios  “seguros”  les  aparece  siempre  el  fallo  y  le  han  dicho  desde  su  propio 
soporte,  “tu  acéptalo  que  es  algo  normal,  porque  sé  yo  que  lo  han  hecho  los  que  montaron  el 
servidor”,  se  genera  la  relación,  “fallo,  es  algo  normal  y  acéptalo”.  Si  la  respuesta  hubiera 
sido  “acéptalo  solo  para  el  acceso  a  esta  web”,  quizás  el  mensaje  hubiera  sido  algo  diferente 
pero  esto  no  suele  ser  lo  que  habitualmente  se  transmite. 

Al  final  la  seguridad  recae  en  el  que  no  debe  recaer,  en  quien  no  está  preparado,  pero 
nuevamente,  a  veces  ni  los  especialistas  técnicos  están  debidamente  preparados.  Han 
pasado  ya  muchos  años  desde  que  detenninados  ataques  que  serán  mostrados  en  este  libro, 
como  el  de  ARP  Poísomng,  salieran  a  la  luz.  Sin  embargo  a  día  de  hoy  el  ataque  resulta 
tan  efectivo  en  muchas  organizaciones  como  el  primer  día  que  se  hizo  público*  Bueno  casi 
mejor,  porque  las  herramientas  han  mejorado  y  cosas  que  hace  años  eran  especulaciones 
ahora  son  una  realidad.  Pero  parece  ser  que  esto  de  la  seguridad  es  parte  y  paranoia  de 
solamente  algunos  y  otras  veces  que  son  meramente  especulaciones  y  no  pasan  en  realidad. 

Bueno  pues  desgraciadamente  pasan  y  también  que  para  atajarlas  hay  que  invertir  en 
tiempo,  personal  y  tecnología.  Si  sumamos  los  factores  de  paranoia  y  es  una  leyenda  urbana 
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con  gastar  en  algo  no  tangible,  resulta  la  ecuación  de  muchas  organizaciones.  Más  de  una 
vez  se  oye  la  voz  de  alguno  más  concienciado,  indicando  que  “esto  puede  llegar  a  pasar  si 
no  se  pone  una  solución”,  Al  final  queda  arrinconado  y  agazapado,  esperando  sacar  pecho 
con  la  frase  lapidaria  de  “dije  que  esto  podía  pasar  y  ha  pasado”. 

Este  libro  va  de  eso,  de  lo  que  podría  llegar  a  pasar.  De  demostrar  que  los  problemas  de 
seguridad  de  las  redes  están  ahí  y  no  son  cosa  del  pasado.  Que  a  pesar  de  que  muchos  de  los 
protocolos  que  se  utilizan  a  día  de  hoy  parecen  seguros  y  muy  modernos,  fueron  ideados  en 
épocas  en  los  que  un  ataque  era  un  “bug”  físico.  De  que  existen  no  obstante  tecnologías  y 
mecanismos  para  luchar  contra  los  ataques  y  que  deben  emplearse  consecuentemente  para 
una  respuesta  común  y  eficiente. 

Cuando  se  diseñan  las  redes  y  sus  protocolos,  se  hizo  pensando  en  que  sean  funcionales  y 
cada  vez: 


más  rápidas. 

tengan  un  mayor  número  de  equipos, 
ofrezcan  más  servicios. 

den  una  respuesta  más  eficiente  ante  las  caídas. 


Es  deseo  que  tras  la  lectura  de  este  libro,  sean  también  más  seguras. 
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Capítulo  II 

Las  redes  de  datos  y  sus  dispositivos 


Las  redes  de  datos  constituyen  a  día  de  hoy  el  núcleo  fundamental  de  operaciones  en  las 
organizaeiones,  todo  pasa  por  ellas.  Hace  años  se  concebía  el  trabajo  en  una  empresa  sin  la 
participación  de  la  informática,  pero  a  día  de  hoy  se  han  convertido  en  algo  tan  necesario  que 
un  fallo  en  las  comunicaciones,  puede  suponer  un  parón  significativo  en  la  foncionalidad  de 
una  organización.  Comunicación  con  clientes,  ventas  de  productos,  operaciones  internas  o 
bancarias  son  alguna  de  las  acciones  dependientes  de  esa  comunicación.  En  esencia  muchas 
empresas  viven  de  ello,  basan  su  negocio  potencial  en  el  uso  de  medios  informáticos  y  en 
las  comunicaciones  asociadas  a  las  mismas. 

Las  infraestructuras  de  comunicaciones,  son  por  lo  tanto  un  punto  neurálgico  por  la  cantidad 
de  datos  que  absorben.  Más  o  menos  críticos  o  importantes,  sensibles  para  la  funcionalidad 
de  la  organización  o  para  el  negocio  en  general,  pero  al  fin  y  al  cabo  datos.  Sin  embargo  por 
la  red  se  traducen  en  simples  1  y  0.  Los  sistemas  infomiáticos  no  traducen  la  sensibilidad 
de  la  infonnación  ni  sus  características,  son  simplemente  datos,  es  el  factor  humano  el  que 
debe  cualificarlos  y  discriminarlos.  La  seguridad  es  de  humanos  no  se  ciñe  a  las  reglas  base 
de  tratamiento  de  los  sistemas  informáticos. 

Las  redes  y  los  protocolos  de  comunicaciones  no  surgen  con  la  idea  de  evaluar  los  datos 
en  función  de  su  criticidad.  Simplemente  cumplen  su  papel:  comunicar.  El  origen  de  las 
mismas  se  remonta  ya  a  muchas  décadas,  en  los  cuales  lo  primordial  era  la  funcionalidad 
el  resto  vendría  detrás.  Las  redes  han  evolucionado,  pero  significativamente  el  elemento 
fundamental  y  aglutinador  ha  sido  siempre  la  ftincionalidad:  que  la  comunicación  exista  es 
la  clave.  El  siguiente  factor  era  la  usabilidad.  Una  red  debe  cumplir  un  propósito  y  hacer 
que  la  misma  fuera  implementable,  el  resto  vendría  detrás. 

Esa  necesidad  de  conectividad,  condicionó  en  gran  medida  la  comunicación  como 
se  entiende  hoy.  Con  el  nacimiento  de  los  ordenadores,  surgió  la  necesidad  de  que  se 
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comunicaran.  Si  un  único  sistema  de  computación  podría  realizar  una  serie  de  operaciones, 
qué  pasaría  si  se  encontraban  unidos.  Los  modeios  teóricos  de  comunicaciones  de  equipos 
son  casi  tan  antiguos  como  los  propios  sistemas  infonnáticos.  La  prioridad  se  basaba  en 
superar  las  trabas  físicas  que  imponían  las  leyes  de  la  naturaleza.  Que  esto  se  tradujera  en 
algo  admisible  a  nivel  informático  ¿por  qué  preocuparse  de  otros  problemas  que  no  eran 
la  prioridad? 

Es  más,  los  modelos  de  comunicación  fueron  creados  por  caballeros  y  para  caballeros. 
¿Quién  se  preocupaba  a  nivel  teórico  de  la  seguridad,  cuando  la  base  era  la  confianza?  No 
había  necesidad  de  proteger  la  información,  solo  de  comunicar.  Los  conceptos  de  hacker, 
la  privacidad  o  la  confidencialidad  se  hallaban  muy  lejos  todavía  de  los  cimientos  sobre  los 
que  se  asentaban  las  comunicaciones. 

La  confiabilidad  era  el  núcleo  primigenio  sobre  la  que  debían  basarse  las  comunicaciones. 
Hay  que  tener  presente  que  muchas  de  las  redes  originales  se  generaron  como  proyectos 
universitarios,  había  un  mundo  por  descubrir  y  por  inventar  Cada  cual  aportaba  su  granito 
de  arena  o  su  proyecto,  pero  irónicamente  faltaba  precisamente  algo  para  las  que  debía  ser 
su  base:  comunicación.  En  la  década  de  los  50  se  trabajaba  ya  en  modelos  de  comunicación 
de  redes  en  los  que  el  esfuerzo  principal,  estaba  en  consonancia  con  el  problema  de  la 
época:  la  gueiTa  fría.  El  ministerio  de  defensa  norteamericano  solicitaba  la  existencia  de 
una  red  que  de  una  u  otra  forma  fuera  resistente  ante  amenazas,  en  el  sentido  de  mantener 
los  sistemas  comunicados.  Por  las  características  de  los  medios  de  comunicación  de  la 
época,  preocupaba  más  las  interrupciones  de  comunicación  entre  los  sistemas  que  la  propia 
seguridad  de  los  datos,  por  muy  sensibles  que  fueran.  La  prioridad  era  establecer  la  conexión 
y  que  fuera  redundante  para  paliar  los  fallos  (cuantiosos)  de  caídas  de  los  elementos  de  los 
medios  de  interconexión.  Hay  que  tener  presente  que  en  la  rnentafidad  de  aquella  época  (no 
obstante  a  día  de  hoy  es  algo  que  también  se  mantiene),  la  seguridad  implicaba  un  coste  y 
por  lo  tanto  había  que  desviar  estos  hacia  otras  necesidades  más  importantes. 

Una  de  las  primeras  grandes  redes  de  comunicación  que  nació  bajo  ese  prisma  fue 
ARPANET  {AdxKmced  Research  Projeets  Agency  Netví^ork).  Teorizada  en  los  años 
60  tenía  como  objetivo  la  unión  de  diferentes  sistemas  infomiáticos  de  organizaciones 
estadounidenses.  Fue  solicitado  como  proyecto  por  el  DOD  (Deparíamento  de  Defensa  de 
los  Estados  Unidos)  donde  las  bases  de  la  funcionalidad  eran: 

-  Implementar  un  sistema  de  comunicación  descentralizado  donde  pudieran  existir 

múltiples  caminos  entre  dos  puntos. 
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-  La  segmentación  de  los  mensajes  en  fracciones  que  pudieran  seguir  caminos 
diferentes. 


La  red  por  lo  tanto  tendría  la  capacidad  de  dar  respuesta  a  sus  propios  fallos.  La  interrupción 
de  uno  de  sus  segmentos  no  debía  imposibilitar  bajo  ninguna  circunstancia  la  caída  del 
sistema.  Dicha  red  consistiría  en  una  serie  de  elementos  de  comunicación  que  conectarían 
los  grandes  sistemas  informáticos  de  diferentes  organizaciones:  ministerios,  universidades, 
sistemas  críticos,  etc.,  teniendo  claro  que  dichos  sistemas  de  comunicación  deberían 
ser  independientes  de  los  grandes  sistemas  de  conmutación.  Se  segmentaban  los  roles: 
sistemas  de  computación  por  un  lado  y  de  comunicación  por  otro.  Cada  uno  cumplía  su 
íunciorialidad  y  por  lo  tanto  se  generaba  la  división,  pero  obligaba  al  hermanamiento  entre 
los  diferentes  sistemas. 

A  la  vez  que  se  diseñaba  y  se  desarrollaba  la  gran  red,  se  hacía  necesario  el  comunicar  los 
sistemas  dentro  de  una  organización.  Teorizar  en  una  red  de  intercambio  de  información 
para  utilizar  medios  existentes  de  la  comunicación  era  una  cosa;  teorizar,  diseñar,  probar  e 
iniplementar  una  micro  red  era  otra  cosa  diferente.  Como  en  otras  múltiples  ocasiones  se 
trabajó  sobre  algo  ya  existente:  la  radio.  La  Universidad  de  Hawai,  ideó  un  mecanismo  que 
hacía  factible  la  interconexión  de  los  diferentes  sistemas  informáticos  entre  las  diferentes 
personas  y  centros  diseminados  en  las  islas  que  conformaban  Hawái,  sin  necesidad  de 
utilizar  un  medio  alquilado  tipo  punto  a  punto  como  hacía  la  red  ARPANET. 

A  diterencia  de  ARPANET  se  buscaba  que  un  mismo  medio  fuera  utilizado  por  múltiples 
sistemas  infomiáticos,  Al  igual  que  el  propio  sistema  de  radio  de  comunicación  tradicional, 
utilizado  por  el  ejército  o  los  radioaficionados,  el  objetivo  era  emplear  un  único  medio  para 
múltiples  comunicantes. 

La  primera  consecuencia  directa  se  basaba  en  cómo  establecer  la  comunicación  de 
dos  o  más  posibles  participantes  donde  todos  actúan  como  emisores  y  receptores.  En 
una  comunicación  de  voz  convencional  entre  dos  únicos  participantes  se  establece  una 
comunicación  simple  de  gestionar,  con  un  protocolo  y  una  toma  de  decisión  para  hablar, 
lo  que  la  convierte  en  una  comunicación  muy  sencilla.  Pero  cuando  interviene  un  tercer 
elemento  la  cuestión  es  más  compleja.  ¿Cómo  se  toma  la  decisión  de  quién  debe  hablar  y 
quién  escuchar?  Al  final  lodo  pasa  por  ser  un  problema  simple,  si  dos  emiten  a  la  vez  en 
una  señal  de  radio  no  puede  existir  comunicación,  se  produce  un  fallo  consecuencia  de  la 
colisión  de  la  señal.  Esta  ha  sido  la  base  de  la  perturbación  de  señales  que  han  utilizado 
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de  manera  táctica  y  estratégica,  unidades  de  Guerra  Electrónica  Militar,  para  anular  las 
comunicaciones  del  enemigo. 

Estos  trazos  de  la  historia  de  las  comunicaciones  sirven  de  ejemplo  para  ver  los  problemas 
a  los  que  se  enfrentaban  los  proyectos  que  nacían.  ALOHANET  ideada  por  la  Universidad 
de  Hawái  proponía  una  solución  a  dicho  problema.  Confiabilidad  y  cortesía  era  la  base 
de  la  comunicación,  hablaba  quien  quería  y  el  resto  esperaba  hasta  la  finalización  de  su 
comunicación.  En  caso  de  que  varios  comunicaran  al  unísono  y  se  produjera  la  colisión 
de  la  comunicación,  se  daban  por  enterados  de  dicho  problema,  iniciándola  nuevamente 
con  un  nuevo  valor  temporal  calculado  por  cada  uno  de  los  dos  sistemas,  con  un  factor  de 
aleatoriedad,  que  impediría  la  colisión  de  las  señales  nuevamente. 

ALOHANET  fue  una  de  las  precursora  del  concepto  de  red  de  área  local  y  sentaba  las  bases 
que  deberían  tenerse  en  cuenta  a  la  hora  de  diseñarse  los  protocolos  en  una  comunicación. 
No  había  que  desdeñar  bajo  ninguna  circunstancia  el  primero  de  los  elementos  en  una 
comunicación,  la  interconexión  física  de  los  elementos.  ARPAN ET  y  otras  lo  tenía  más 
o  menos  resuelto  porque  utilizaban  medios  existentes,  pero  para  otros  conceptos  de  redes 
debían  diseñarse  también  los  elementos  físicos  y  dar  solución  al  entendimiento  de  todos  los 
que  deseaban  comunicar  en  un  mismo  medio. 

ALOHANET  presentaba  un  problema  y  se  ideó  un  mecanismo  que  hacía  factible  la 
comunicación  mejorando  el  algoritmo  de  la  comunicación:  CSMA-CD  {Carrier  Sense 
Múltiple  Access  with  Collision  Detection).  La  idea  base  es  estar  en  modo  de  escucha  y 
si  hay  algo  que  comunicar  esperar  a  que  el  medio  esté  libre  de  portadora.  En  caso  de 
producirse  una  colisión  de  la  señal,  deberá  esperar  un  'Tiempo  prudencial  aleatorio”  para  la 
transmisión  nuevamente  de  la  comunicación. 

La  red  de  radio  de  aquella  época  presentaba  sus  inconvenientes,  sistemas  aparatosos, 
supeditado  a  las  condiciones  ambientales,  fácilmente  perlurbable  y  de  complicada 
implementación.  En  un  espacio  reducido  donde  intervinieran  varios  sistemas,  las  señales 
emitidas  en  una  misma  frecuencia  podrían  llegar  a  acoplarse.  Por  lo  tanto  la  alternativa 
estaba  clara,  el  cable  sería  el  método  más  efectivo  para  la  comunicación  de  sistemas 
internos  en  una  organización. 

Debía  por  lo  tanto  trasladarse  todo  lo  diseñado  para  sistemas  radio  a  unos  sistemas  cableados. 
Era  necesario  por  lo  tanto  diseñarse  elementos  hardware  de  conexión  e  ímplemeiitar  sobre 
ellos  el  ya  probado  método  de  CSMA-CD  como  sistema  para  garantizar  la  conexión  en 
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la  capa  física*  Este  sistema  de  CSMA-CD  evolucionará  en  el  actual  método  conocido  de 
Ethernet,  aunque  con  los  debidos  cambios  necesarios  motivados  por  las  necesidades  de 
implemcntación  y  mejora.  Las  circunstancias  eran  por  lo  tanto  claras: 

-  Se  deseaba  un  sistema  de  comunicación  simple. 

-  Debía  estar  basado  en  la  confianza  de  los  que  la  establecían* 

-  Podria  ser  compatible  con  los  protocolos  de  comunicación  que  a  nivel  superior 
se  estaban  diseñando* 


Hay  que  tener  en  cuenta  que  a  la  vez  que  se  ideaban  estos  sistemas  de  comunicación  a  nivel 
físico,  estaba  en  pleno  apogeo  también  el  desarrollo  de  protocolos  a  nivel  de  aplicación* 
Por  poner  ejemplos  FTP  {File  Transfer  Protocot)  o  SMTP  {Simple  Mail  Tramfer  Protocol), 
datan  de  principios  de  los  años  70. 

Los  componentes  diferenciados  para  establecer  una  comunicación  necesitaban  un  doble 
elemento  para  que  fuera  efectivo; 

-  Conexión  a  nivel  físico. 

-  Conexión  a  nivel  lógico. 


Los  desarrollos,  aunque  dependientes  en  características  unos  de  otros,  requerían  que 
su  funcionamiento  pudiera  ser  independientemente  implementado.  Por  ejemplo  la 
comunicación  física  cableada  en  la  red,  requería  a  su  vez  unos  protocolos  que  pennitieran 
la  identificación  de  las  estaciones  con  objeto  de  que  la  comunicación  fuera  encaminada 
de  forma  efectiva.  Dichos  protocolos  deberían  ser  independientes  de  Ethernet.  Aunque  a 
día  de  hoy  todo  se  encuentra  asociado  a  TCP/IP,  durante  muchos  años  existieron  otros 
protocolos  no  menos  importantes,  tales  como  IPX/SPX  (Interuetwork  Pocket  Exchange/ 
Sequenced  Pocket  Exchange)  o  NetBeui.  Cada  uno  de  ellos  a  su  forma  empleaba  Ethernet 
como  mecanismo  de  acceso  al  medio.  Para  garantizar  la  comunicación  inequívoca  dentro 
de  la  red,  utilizaban  sus  propios  mecanismos  de  identificación  de  los  sistemas. 

No  solo  Ethernet  era  el  mecanismo  ideado,  también  las  comunicaciones  basadas  en  Token 
competían  como  sistemas  de  implcmentación  física  de  las  comunicaciones.  Frente  a  las 
primeras  que  establecían  la  libertad  para  la  comunicación  de  cualquier  sistema  unido  al 
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medio  y  donde  las  colisiones  eran  un  error  a  asumir,  las  segundas  pugnaban  por  evitar 
la  colisión.  A  través  de  la  posesión  del  testigo  se  establecía  quién  podía  o  no  enviar  una 
comunicación.  Se  evitaba  la  colisión  puesto  que  solo  podría  enviar  datos  aquel  sistema  que 
estuviera  en  posesión  del  testigo. 

Cada  sistema  ofrecía  sus  ventajas  e  inconvenientes,  solo  el  tiempo,  el  crecimiento  de 
las  redes  y  otros  factores  económicos  y  de  evolución  de  mercado,  hizo  que  las  redes  de 
tipo  Ethernet  acabaran  prevaleciendo.  No  obstante  aunque  puedan  formar  parte  de  la 
historia,  las  especificaciones  de  las  redes  Token  Ring  y  Token  Bus,  las  hacían  idóneas  para 
detenninados  tipos  de  escenarios. 

Este  conglomerado  de  escenarios,  estudios  y  medios  técnicos  que  iba  surgiendo  a  nivel 
físico,  había  que  compatibilizarlo  con  la  comunicación  a  nivel  lógico.  Por  lo  cual,  cuanto 
más  sencillo  pudiera  ser  todo,  más  compatibilidad  ofrecería.  Hay  que  tener  en  cuenta 
que  la  seguridad  tiende  a  complicar  todos  los  aspectos  y  en  la  comunicación  no  iba  a  ser 
menos.  Es  por  ello  que  los  planteamientos  iniciales  tenían  como  fundamento  que  todo 
fuera  lo  más  funcional  y  factible  posible,  máxime  cuando  había  necesidades  de  que  todo 
se  implementara  cuanto  antes,  ARPANET  era  una  realidad,  los  protocolos  de  interface 
humana  también,  por  lo  que  corrían  prisa  las  implementaciones.  Quizás  se  hizo  lo  más 
fácil  en  aquel  momento,  pero  esto  condicionaba  y  hacía  más  complejo  el  futitro.  Se  empleó 
un  modelo  ya  probado  como  TCP/IP  para  ARPANET,  aunque  no  fuera  el  mejor  diseño 
lógico  para  la  comunicación,  dejando  aparte  las  teorías  de  diseños  más  eficaces  que  iban  a 
ser  consensuados  y  analizados  con  más  tiempo.  El  paso  del  tiempo  hizo  que  el  modelo  ya 
funcional  acabara  por  imponerse  sobre  otros  modelos  más  teóricos  y  con  un  diseño  más 
elaborado. 

TCP/IP  ofrecía  posibilidades  de  uso  a  todos  los  niveles,  redes  de  área  local,  metropolitanas 
y  externas,  con  una  implementación  más  o  menos  simple,  ya  en  pruebas  y  con  una  curva 
de  aprendizaje  relativamente  rápida.  Pero  TCP/IP  a  nivel  lógico  planteaba  las  mismas 
circunstancias  que  Ethernet,  era  un  sistema  basado  en  la  confianza,  donde  la  seguridad  no 
era  la  prioridad.  Daba  respuesta  rápida  a  las  necesidades  que  se  planteaban.  Compatible 
con  Ethernet  y  el  resto  de  mecanismos  de  comunicación  a  nivel  lógico,  vivió  una 
implementación  rápida  dotando  de  protocolos  que  permitieran  que  la  comunicación  a  nivel 
física,  pudiera  convivir  con  la  comunicación  a  nivel  lógica.  Todo  se  armaba  rápidamente 
y  debía  ser  adaptado  con  prontitud  a  unas  necesidades  de  uso  tecnológicos  cada  vez  más 
emergentes. 
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Las  redes  de  datos  iban  a  experimentar  un  crecimiento  significativo,  tanto  en  el  núiTiero  de 
sistemas  interconectados  como  en  la  cantidad  de  datos  a  transmitin  TCP/IP  iba  ofireciendo 
sol  Liciones,  solo  era  necesano  que  las  tecnologías  hardware  fueran  consecuentes  con  esa 
evolución.  Y  estas  ofrecieron  esa  evolución  natural. 

Las  evoluciones  de  las  redes  ARPANET  a  su  nivel  y  las  de  área  local  como  Ethernet  o  las 
basadas  en  Token,  requerían  de  la  comunicación  mediante  dispositivos  a  nivel  físico.  Cada 
una  de  ellas  a  la  larga  utilizarían  las  suyas,  este  libro  estará  fundamentado  en  Ethernet 
puesta  que  se  ha  convertido  en  el  sistema  de  comunicación  de  red  de  área  local  cableada 
más  frecuentemente  empleado.  Estos  sistemas  físicos  no  debían  encontrarse  supeditados  a 
ningún  protocolo  de  nivel  lógico,  pero  en  esencia  acabarían  por  verse  condicionados.  La  red 
ARPANET  se  i mpl ementaba  físicamente  sobre  un  sistema  de  comunicación  ya  existente 
que  permitía  interconectar  los  diterentes  elementos  conectados  a  ellos.  Sin  embargo  las 
redes  de  área  local  requerían  de  la  creación  de  nuevos  sistemas  tísicos  o  bien  reutilizar 
elementos  ya  existentes. 

Los  sistemas  de  cable  por  lógica  se  imponían  sobre  los  sistemas  inalámbricos.  Curiosamente 
en  un  ciclo  natura!  años  más  tarde  las  necesidades  de  crecimiento  de  las  organizaciones  y 
la  aparición  de  nuevas  tecnologías  retomarían  los  sistemas  de  comunicación  inalámbricos 
en  redes  de  área  local,  clai^o  está  con  ía  consabida  evolución  de  los  mismos.  Una  red  de 
cable  y  un  número  limitados  de  equipos  hacia  factible  una  red  en  modo  BUS.  Todos  los 
equipos  conectados  a  un  único  hilo  central  permitía  un  crecimiento  moderado  de  una  red 
escasa  de  equipos  y  con  unos  costes  mínimos:  adaptadores  de  red  para  la  conexión  al  cable, 
el  propio  cable  y  los  conectores  correspondientes.  Su  arquitectura  era  muy  simple.  La  señal 
era  remitida  por  una  estación  a  las  dos  direcciones  factibles  y  esta  seria  recogida  por  el  resto 
de  equipo  de  tal  forma  que  fuera  procesada  correctamente. 

Su  versatilidad  residía  en  que  el  crecimiento  de  la  red  era  factible  a  un  coste  más  o  menos 
cómodo,  pero  también  era  su  talón  de  Aquiles.  Cuanto  mayor  era  el  tamaño  de  la  red  mayor 
coste  en  tiempo  requería  una  comunicación  completa  y  mayor  era  la  probabilidad  de  que  se 
produjeran  colisiones.  También  existían  unos  problemas  físicos  que  no  podían  evitarse:  la 
pérdida  de  intensidad  de  la  señal  y  el  tamaño  máximo  que  podía  alcanzar  la  red  en  función 
del  tamaño  máximo  de  una  trama  tipo  Ethernet. 

No  obstante  el  problema  fundamental  de  este  tipo  de  red  (las  basadas  en  bus  plantean  los 
mismos  problemas),  consistía  en  que  un  problema  físico,  en  la  línea  de  cobre  iiTiplicaba  la 
caída  de  toda  la  red  de  equipos  conectada  a  la  misma.  Nuevamente  cuanto  mayor  longitud 
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de  la  línea,  mayor  será  el  incremento  en  la  posibilidad  de  una  caída  de  la  red  debido  esta 
vez  a  problemas  de  índole  físico. 

Por  lo  tanto  el  cambio  tecnológico  era  una  necesidad,  motivado  fundamentalmente  por 
el  crecimiento  de  los  equipos  que  eran  conectados  a  una  red.  Aunque  incrementando 
los  costes,  había  que  desechar  una  red  en  bus.  El  concepto  fundamenta!  diametral  mente 
opuesto  es  una  red  en  estrella  Si  el  problema  fundamental  era  la  figura  del  cable,  podría 
limitarse  el  problema  eliminándola  como  elemento  aglutinador  de  la  red,  sustituyéndolo 
por  una  tecnología  más  robusta,  y  también  más  cara.  Los  concentradores  de  señal  (HUB), 
ofrecían  la  solución.  A  costa  de  una  inversión  tecnológica  superior  (una  electrónica  más 
robusta),  se  eliminaba  la  figura  del  canal  único  de  señal  que  se  ofrecía  a  través  de  un 
cable.  Evidentemente  no  se  sustituía  la  figura  del  cobre,  de  alguna  forma  hay  que  llevar 
la  información  de  los  equipos  al  concentrador,  pero  se  eliminaba  el  vector  principal 
del  problema,  si  uno  de  los  cables  que  enlazan  el  equipo  y  el  concentrador  presenta  un 
problema,  este  queda  aislado,  pero  no  afecta  negativamente  al  resto  de  sistemas  que  podrán 
comunicarse. 

Este  cambia  tecnológico  además  ofrecía  más  cambios  fundamentales,  como  son  la  velocidad 
y  la  distancia.  La  figura  del  concentrador  hacía  también  funciones  de  repetidor  por  lo  que 
la  señal  podría  ser  amplificada,  evitando  de  esta  forma  la  pérdida  de  la  señal  típica  en  las 
redes  de  bus.  Acercaba  adicionalmente  la  distancia  de  los  equipos,  por  lo  que  las  colisiones 
(existen  debido  a  que  la  tecnología  seguía  siendo  de  tipo  Ethernet)  se  daban  pero  en  menor 
frecuencia  que  en  una  red  de  bus  en  igualdad  de  equipos. 

Sin  embargo,  nadie  se  preocupó  de  la  seguridad,  no  era  lo  vital,  simplemente  había 
necesidad  de  conectar  a  más  equipos  y  hacer  que  la  velocidad  se  incrementara.  A  día  de 
hoy  en  algunos  entornos  se  habla  de  que  una  red  conectada  a  través  de  dispositivos  HUB 
es  una  red  de  tipo  confianza.  La  explicación  era  simple,  no  existe  privacidad.  La  señal  que 
era  dirigida  hacia  un  equipo  en  la  red  era  remitida  por  todos  los  puertos  del  dispositivo, 
llegando  así  a  lodos  los  equipos  que  se  hallan  conectados  al  mismo.  Dentro  de  la  ventaja 
tecnológica  que  se  asumía  en  la  ¡mplementación  de  dispositivos  concentradores,  la  base 
fundamental  era  la  repetición  de  la  señal.  No  se  aplicaba  una  lógica  para  el  renvío  de  dicha 
información  a  una  estación  concreta,  todos  recibían  los  paquetes  y  cada  sistema  asumiría  o 
rechazaría  el  mismo  dando  la  contestación  pertinente. 

El  paso  del  tiempo  hacia  inevitable  otro  salto  tecnológico,  limitado  fundamentalmente  por 
dos  factores;  mayor  número  de  equipos  y  mayor  caudal  de  tráfico.  El  aumento  del  número 
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de  equipos  en  una  red  incrementa  de  forma  lógica  la  necesidad  de  comunicación  entre  los 
mismos  .  Esta  necesidad  de  comunicación  aumenta  adicional  mente  la  probabilidad  de  que 
se  produzcan  colisiones,  con  lo  cual  no  sólo  se  ha  producido  el  fallo  de  la  comunicación, 
sino  que  además  esas  tramas  que  se  han  cortado  y  no  han  llegado  a  su  destino,  implican 
además  que  tengan  que  volver  a  reenviarse.  El  problema  fundamental  es  que  se  va  a  generar, 
más  tráfico  si  cabe. 

Adicionalmente  en  los  sistemas  iba  evolucionando  la  interfaz  humana  de  la  informática,  tenía 
más  que  ofrecer  a  los  usuarios  para  hacerlas  más  cómodas  y  usables.  Se  ganaba  en  potencia 
de  procesamiento,  en  la  misma  interrelación  de  las  aplicaciones  y  en  la  gestión  centralizada 
de  toda  la  infonnación.  Por  lo  tanto  el  caudal  de  tráfico  que  absorbían  las  redes  iba  a  su  vez 
en  crecimiento.  Es  más,  un  problema  en  un  equipo  que  emitiera  hacia  otro  tráfico  de  forma 
continuada  sin  control,  podía  provocar  la  anulación  de  la  red  por  saturación  y  posterior 
desbordamiento.  También  suponen  un  problema  los  bucles  generados  en  comunicaciones 
al  conectar  dos  dispositivos  o  una  cascada  de  ellos  través  de  dos  conexiones  físicas 
concurrentes.  Se  genera  así  un  circuito  cerrado  donde  una  única  trama  podría  estar  siendo 
transmitida  innecesariamente  de  forma  continua  hacía  todos  los  sistemas.  Sin  embargo  lo 
de  conectar  dos  dispositivos  HUB  con  dos  cables  tenía  la  explicación  en  la  mente  práctica 
de  muchos,  obtener  redundancia  e  intentar  ganar  caudal  de  conexión  donde  realmente  era 
necesaria,  entre  los  dispositivos.  Sin  embargo  se  genera  el  problema  inverso,  fallo  en  la 
conectividad  derivada  por  ejemplo  a  través  de  una  tormenta  de  Broadcast. 

Mas  concentradores  no  ofrecían  una  solución  porque  al  final  la  señal  viajaba  por  todos  los 
elementos  del  sistema.  Había  por  lo  tanto  que  fraccionar  la  red,  mejorar  el  rendimiento 
de  la  comunicación  y  aislar  los  problemas.  Si  los  concentradores  suponían  la  solución  de 
comunicación  física  en  el  nivel  1  de  ia  comunicación,  se  hacía  necesario  escalar  en  las 
capas  para  ofrecer  una  solución  mejorada.  En  el  modelo  teórico  OSI,  la  capa  2  o  de  enlace 
de  datos  ofrecía  la  capacidad  de  dotar  a  los  sistemas  de  una  dirección,  de  control  de  flujo, 
de  control  errores  y  en  general  de  poder  mediatizar  la  comunicación. 

La  capa  2  es  ampliamente  utilizada  en  todo  tipos  de  conexiones  bien  sean  LAN  o 
WAN,  y  en  muchas  circunstancias  pasan  desapercibidas  pero  son  fundamentales  para 
la  comunicación.  El  protocolo  PPP  {Poínt  to  Pomt  Protoeoí)  o  HDLC  {High  Dala  Link 
Control)  son  dos  claros  ejemplos  adicionales  a  la  capa  de  enlace  de  las  redes  tipo  Ethernet 
o  de  las  comunicaciones  inalámbricas  actuales.  Sin  embargo,  y  nuevamente,  no  se  pensaba 
en  seguridad,  simplemente,  en  más  cantidad  y  más  rápido. 
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Los  dispositivos  de  capa  2  que  surgen  como  los  Switch  o  conmutadores,  ofrecían  unas 
condiciones  de  conectividad  más  óptimas  que  las  que  aportaban  los  concentradores  del 
nivel  inferior.  Generan  la  figura  de  los  dominios  de  colisión.  El  objetivo  era  controlar 
precisamente  un  gran  problema,  ¿Sí  un  sistema  necesitaba  enviar  la  información  a  un 
único  punto,  por  qué  enviárselo  a  todos?  Un  efecto  colateral  era  la  seguridad,  pero  no  la 
base  fundaiuentaL  Si  el  tráfico  de  un  equipo  era  dirigido  exclusivamente  hacia  un  sistema, 
se  podía  permitir  múltiples  comunicaciones  de  forma  concurrente.  Se  descongestiona 
el  tráfico,  se  puede  aumentar  el  caudal  y  se  pueden  aislar  los  elementos  problemáticos 
con  controles,  pudiendo  limitar  así  el  tráfico  de  equipos  que  envían  señales  de  forma 
descoíitrolada.  Por  ejemplo  los  controles  de  tormenta  de  Broadeast  o  las  implementaciones 
de  STP  {Spanmng  Tree  Protocol),  con  objeto  de  detectar  y  dar  solución  a  potenciales  bucles 
en  la  infraestmetura  de  comunicaciones* 

La  capa  de  enlace  otrece  esas  cualidades,  solo  implicaba  un  mejor  diseño  de  dispositivos, 
tecnología  y  capacidades  que  las  que  ofrecían  hasta  la  fecha  los  concentradores*  Un 
dispositivo  Switch  podría  hacer  perféctamente  lo  mismo  que  un  HUB  pero  con  más 
capacidad.  Eso  evidentemente  tenía  su  contrapartida:  el  coste  económico.  Hasta  que  la 
necesidad  tecnológica  contrarrestada  con  el  abaratamiento  de  los  Swdtch  no  alcanza  una 
paridad  razonable,  este  tipo  de  dispositivos  no  acaba  por  entrar  en  las  organizaciones.  A 
día  de  hoy  el  coste  de  estos  aparatos  en  comparación  con  los  clásicos  concentradores  es 
prácticamente  despreciable,  teniendo  además  en  cuenta  el  salto  tecnológico  que  se  producía. 
Sin  embargo  a  principio  de  este  siglo  la  diferencia  era  muy  significativa* 

Llevar  la  infonnación  de  un  sistema  a  otro  sin  que  llegara  a  todos  es  la  clave,  por  lo 
tanto  se  necesitaba  direccionar  Que  los  sistemas  poseyeran  algo  que  los  hiciera  únicos 
a  nivel  2  y  que  estos  dispositivos  tuvieran  la  capacidad  para  entenderlo  era  la  clave.  Las 
especificaciones  originales  IEEE  802,  ofrecían  corno  solución  una  dirección  denominada 
MAC  {Medía  Control\  como  mecanismo  de  asignación  universal  de  direcciones 

administradas. 

Una  dirección  MAC  consta  de  dos  grupos  de  valores*  El  primero  denominado  OUI 
{Organizationally  Unique  identifier\  designa  a  la  organización  fabricante  de  un  dispositivo, 
cuestión  que  se  encuentra  totalmente  regulado  por  un  organismo  único.  El  resto  de  valores 
designan  la  asignación  única  que  dicho  fabricante  asigna  al  dispositivo  dentro  del  espacio 
de  direcciones  que  le  han  asignado.  Aunque  tradicionalmente  se  asume  como  dirección 
MAC  una  de  tipo  48  bit,  este  dato  no  es  del  todo  correcto,  puesto  que  además  de  esta  existe 
otra  de  longitud  64  bit.  Se  denominan  convencionalmente  MAC-48  o  EUÍ-48  y  EUl-64. 
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Las  siglas  EUI  atienden  a  Extender  Uniqiie  identífier.  Aunque  la  frecuentemente  utilizada  es 
la  de  tipo  EUI-48,  se  prevé  el  agotamiento  del  espacio  de  direcciones  y  por  lo  tanto  al  igual 
que  ha  sucedido  con  lPv6»  se  pretende  que  EUl-64  venga  a  dar  respuesta  a  esa  necesidad 
de  mayor  número  de  direcciones.  La  notación  en  hexadecimal  de  dichas  direcciones,  ha 
hecho  que  para  una  más  fácil  comprensión  humana  la  división  de  las  mismas,  se  realice  en 
octetos.  Así  tanto  en  una  dirección  ELII-48  como  en  una  dirección  EUl-64  los  primeros  24 
bits  designan  a  una  organización,  el  resto  de  bits,  mayores  en  las  de  tipo  EUl-64,  40  frente 
a  24,  se  utilizarán  para  la  identificación  del  dispositivo. 

Esta  dirección  MAC  o  también  conocida  comúnmente  como  dirección  física,  es  utilizada 
para  llevar  los  paquetes  a  nivel  de  capa  2,  además  de  identificar  elementos  en  una  red.  Solo 
quedaría  por  detenninar  como  los  sistemas  son  capaces  de  aprender  las  direcciones  físicas 
del  resto  de  equipos  de  la  red.  Esto  será  tratado  extensamente  a  lo  largo  de  otros  capítulos 
puesto  que  será  necesaria  la  intervención  de  los  protocolos  lógicos  para  ello. 

Con  esta  información  los  Switch  tendrán  la  capacidad  de  almacenar  en  sus  tablas  las 
direcciones  físicas  que  conocen  y  aprenden,  asociándolos  a  los  diferentes  puertos  que 
poseen.  De  esta  forma  cuando  una  trama  dirigida  de  MAC  A,  tenga  como  dirección  única 
MAC  B,  el  dispositivo  la  podrá  retransmitir  a  través  del  puerto  correspondiente.  Si  por  algún 
motivo  dado  MAC  B  estuviera  estableciendo  una  comunicación  en  ese  mismo  momento 
con  otro  sistema,  MAC  C,  la  mejora  tecnológica  de  los  Switch,  permitiría  almacenar 
la  trama,  hasta  que  la  comunicación  entre  MAC  B  y  MAC  C,  finalizara  o  bien  fuera 
gestionada  convenientemente  por  el  dispositivo.  Solucionado  inicialmente  el  problema  de 
las  colisiones,  se  daba  una  solución  al  problema  del  caudal  de  la  comunicación.  No  obstante 
existía  un  problema  fundamental  de  base  que  no  tiene  solución  y  que  de  una  u  otra  forma 
la  tecnología  la  ha  asumido  como  un  mal  menor  hasta  IPv6:  las  tramas  tipo  Broadeast.  La 
funcionalidad  de  los  Switch  es  óptima  en  las  condiciones  de  una  comunicación  totalmente 
dirigida:  tramas  Unicast.  Pero  claro  está  no  todo  el  tráfico  es  dirigido  a  un  sistema  concreto, 
en  ocasiones  una  trama  no  tiene  un  destino  concreto  puesto  que  se  desconoce.  El  más 
claro  ejemplo  es  la  de  identificar  la  dirección  MAC  de  un  equipo  del  que  se  tiene  otra 
información  como  su  nombre.  Puesto  que  no  existe  la  información  de  capa  2  necesaria  para 
entablar  la  comunicación,  es  necesario  adquirirla,  preguntando  a  todo  el  sistema  cuál  es 
dicha  información:  trama  de  tipo  Broadeast. 

Puesto  que  son  necesarias  estas  tramas  en  las  condiciones  de  trabajo  convencionales,  se 
asumen  como  un  mal  menor,  excepto  en  aquellas  circunstancias  en  las  cuales  un  aumento 
desorbitado  de  dicho  tráfico  ocasione  la  ya  mencionada  tonnenta  de  hroadeast.  Esta  podría 
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llegar  a  inutilizar  una  red  comunicada  por  Switch  de  la  misma  forma  que  sucedería  con  una 
red  de  Hub. 

La  aparición  de  los  Switch  ofreció  algo  muy  importante:  velocidad  y  caudaf  y  colateralmente 
una  relativa  sensación  de  seguridad.  El  tráfico  era  dirigido  de  un  extremo  a  otro  sin  que  nadie 
del  entorno  fuera  receptor  de  dicha  comunicación.  Por  lo  tanto  existe  la  '‘falsa  creencia”  de 
que  con  un  Switch  es  imposible  obtener  un  tráfico  entre  dos  entidades. 

Por  lo  cual  hasta  este  momento  caben  desprenderse  una  serie  de  ideas. 

-  La  idea  fundamental  es  la  conectividad:  primero  que  funcione  y  ei  resto  vendrá 
después. 

-  Cuando  la  idea  es  funcional,  se  avanza  en  mejorar  otras  características:  servicios, 
velocidad  y  caudal. 

-  Los  protocolos  e  ideas  precursoras  se  diseñan  con  el  propósito  fundamental  de 
que  sean  funcionales. 

-  La  evolución  de  la  tecnología  Hardware  representa  la  esencia  de  la  necesidad: 
que  todo  sea  más  rápido  y  se  pueda  unir  una  mayor  cantidad  de  sistemas, 

-  La  confianza  es  la  base  de  la  comunicación. 

Por  lo  tanto  un  mundo  diseñado  por  caballeros  y  para  caballeros,  no  para  tiempos  actuales. 
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Capítulo  III 

Sniffíng,  Spoofíng  y  Haijacking 


La  evolución  natural  acerca  de  “más  cantidad”  y  “más  rápido”  tal  y  como  se  cuenta  en  el 
capítulo  anterior  representa  un  reflejo  de  la  condición  humana.  No  obstante  también  es  parte 
de  esa  idiosincrasia  la  de  enterarse  de  lo  que  sucede  alrededor.  Poseer  información  es  poder. 
Ha  hecho  ganar  o  perder  batallas,  aupar  o  derrocar  líderes,  hacer  crecer  o  hundir  empresas. 
La  información  se  quiere,  se  maneja  y  se  altera.  De  esto  trata  este  eapitulo  simplemente  de 
tratar  la  información  desde  el  otro  lado. 

La  informática  trata  precisamente  de  eso,  de  la  automatización  de  la  información.  Los 
volúmenes  que  adquieren  a  día  de  hoy  no  son  ya  ni  siquiera  cuantificables.  La  hay 
más  sensible  o  menos,  más  o  menos  pública,  pero  en  esencia  todo  representa  un  valor. 
Lo  único  necesario  para  obtenerla  es  escuchar.  Tal  y  como  se  mencionó  en  el  capítulo 
anterior  los  primeros  sistemas  de  comunicación  con  la  tecnología  Ethernet  consistían 
en  una  comunicación  tipo  bus  donde  el  tráfico  era  dirigido  hacia  todos  los  sistemas, 
fundamentalmente  por  necesidades  físicas.  Si  no  hay  conciencia  de  donde  está  el  sistema 
con  el  cual  comunicarse  habrá  que  hacer  llegar  la  información  a  todos  los  lugares.  También 
se  ha  hablado  de  la  tecnología  CSMA-CD,  donde  los  sistemas  están  en  modo  de  escucha  a 
la  espera  recibir  una  comunicación  y  evaluar  si  hay  que  procesarla. 

Este  proceso  de  evaluación  es  simple:  “la  información  viene  para  mí”.  Si  es  así  la  procesa, 
si  no  la  descarta,  ¿Qué  implica  este  hecho  de  es  para  mí?  En  la  condición  actual,  sería 
sinónimo  de  “es  mi  MAC,  es  mi  IP,  es  mi  nombre”,  si  la  respuesta  es  afirmativa  entonces 
“es  para  mí”.  La  circunstancia  peculiar  radica,  en  qué  condiciona  a  un  sistema  al  que  le  ha 
llegado  la  trama  y  no  va  dirigida  hacia  él,  el  que  pueda  procesarla  ¿caballerosidad?  Quizás 
sea  la  base,  pero  hay  que  recordar  la  última  frase  del  anterior  capítulo. 

Con  la  información  llegando  al  sistema,  no  existe  mecanismo  para  evitar  que  pueda  ser 
procesada  por  quien  no  debiera.  Sniff  (olfatear)  se  ha  denominado  a  la  técnica  que  limita 
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precisamente  ese  ápice  de  caballerosidad  con  el  que  se  ideó  la  tecnología  de  la  comunicación. 
Elimina  ese  elemento  que  hace  que  un  sistema  de  forma  natural  rechace  un  tráfico  no 
dirigido  hacia  él,  haciéndolo  así  proclive  a  procesar  cualquier  información  que  le  llegue: 
el  modo  promiscuo.  El  sniffer  es  simplemente  la  herramienta  que  hace  eso,  permite  que  un 
sistema  (o  más  bien  tarjeta  de  red)  tenga  un  comportamiento  promiscuo.  Adicionalmente  es 
capaz  mediante  una  interfaz  el  mostrar  la  intórmación  obtenida,  teniendo  la  capacidad  en 
función  de  la  mayor  o  menos  sofisticación  de  la  herramienta,  de  poder  agrupar  las  tramas 
haciéndolas  fácilmente  interpretables. 

Existe  la  falsa  creencia  de  que  un  sníjfer  instalado  en  un  equipo  implica  automáticamente 
que  se  va  a  “capturar'’  todo  el  tráfico  de  la  red,  o  bien  que  todos  los  sniffer  son  por 
antonomasia  maliciosos.  Pues  bien  ninguna  de  las  dos  es  verdadera. 

La  primera  de  las  circunstancias  depende  inicialmente  del  tipo  de  arquitectura  de  red 
donde  se  encuentre  instalado  el  sniffer.  En  una  red  Ethernet  tipo  bus  o  en  estrella  con 
dispositivos  HUB,  los  paquetes  llegan  a  todos  ios  sistemas  conectados  a  la  red.  Realmente 
los  Sniffer  no  capturan  el  tráfico,  simplemente  les  llegan  y  lo  procesan.  En  una  red  Ethernet 
con  dispositivos  Su'itch,  esto  no  es  así,  fundamentalmente  puesto  que  las  tramas  tienen 
un  origen  y  destino  concreto  a  nivel  de  capa  2  y  los  conmutadores  hacen  que  esto  se  haga 
efectivo.  De  esta  fomia  un  tercero  no  recibirá  la  conversación  mantenida  por  otros  dos 
sistemas  en  una  red  donde  existieran  conmutadores. 

El  comportamiento  tipo  promiscuo  no  es  utilizado  exclusivamente  con  un  objetivo 
potencial  mente  malicioso.  También  se  emplea  como  técnica  para  analizar  el  compoitamiento 
de  una  red  o  bien  con  propósitos  forenses*  Si  unos  sistemas  presentan  un  comportamienlo 
anómalo  podría  ser  interesante  analizar  el  tráfico  con  objeto  de  detectar  la  causa  de  dicha 
anomalía.  Si  por  ejemplo  se  está  sufi'iendo  un  ataque,  el  análisis  de  dichos  paquetes  permitiría 
llegar  a  determinar  las  circunstancias  que  está  provocando  que  se  produzca  la  anomalía. 
Los  sistemas  de  detección  de  intrusiones  (IDS),  son  sistemas  de  análisis  preventivo  y 
reactiva,  que  analizan  bien  en  tiempo  real  o  bajo  demanda  detenninados  segmentos  de  red 
con  objeto  de  determinar  unas  posibles  incidencias*  Puesto  que  los  sistemas  IDS  no  son  los 
destinatarios  de  dicha  comunicación,  necesitan  tener  ese  comportamiento  promiscuo  para 
poder  analizar  el  tráfico. 

Habilitar  el  modo  promiscuo  es  diferente  en  función  del  sistema  operativo.  En  los  sistemas 
Linux  se  puede  realizar  mediante  la  sintaxis  ifeonfig  <adaptador>  promisc. 
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Fig,  3,1-  Modo  Promiscuo  Linux. 


En  los  sistemas  Windows  se  realiza  mediante  la  implementación  de  drivers  o  determinado 
software.  El  ejemplo  más  significativo  lo  constituye  la  herramienta  WinPeap  {http://wH^. 
winpcap.org/),  que  pennite  la  captura  de  tráfico  proporcionando  adicional  mente  una  serie 
de  librerías  para  el  filtrado  de  información. 
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Fíg.  3.2.-  ñ'inPcap. 


En  las  conclusiones  anteriores  se  indicaba  que  no  todos  los  componentes  sniffer  deben  ser 
tomados  como  maliciosos.  Se  mostraban  escenarios  en  los  cuales  podrían  ser  beneficiosos 
para  una  organización.  ¿Y  qué  pasa  con  las  redes  con  tecnología  Swáteh?  SÍ  la  información 
no  llega  hacia  ellos  puesto  que  no  son  origen  ni  destino  ¿pierden  funcionalidad?  Para 
esto  nuevamente  la  tecnología  ofrece  posibilidades.  Quizás  la  más  eficiente  consista  en  la 
capacidad  que  presentan  determinados  Swntch  de  replicar  el  tráfico  de  todos  sus  puertos,  (o 
bien  de  determinados  de  ellos)  a  otros  dentro  del  dispositivo.  De  esta  forma  todo  el  tráfico 
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podrá  llegar  al  IDS,  sin  necesidad  de  pérdida  de  la  conectividad.  El  tráfico  de  A  a  B  no  pasa 
originalmente  por  el  IDS.  Si  se  habilita  esta  replicación,  el  tráfico  de  A  llega  a  B  y  también 
es  redirigido  por  el  Switch  al  puerto  donde  se  encontrará  el  IDS.  Este  tipo  de  tecnología 
difiere  en  función  del  fabricante  y  el  dispositivo.  No  todos  lo  poseen  ni  mucho  menos,  pero 
el  objetivo  es  común:  dotar  de  la  capacidad  de  analizar  tráfico. 

Esta  funcionalidad  ofrece  una  paradoja  muy  peculiar  de  la  que  no  son  conscientes  muchas 
empresas.  Estas  adquieren  dispositivos  Switch  y  los  implementan  en  sus  infraestructuras 
en  modo  "'pinchar  y  listo”.  Para  ellas  no  son  ni  más  ni  menos  que  meros  elementos  de 
comunicación.  Desconocen  o  bien  no  quieren  o  no  necesitan  implementaciones  tecnológicas 
por  las  cuales  ya  han  pagado:  redes  virtuales  de  área  local  (VEAN),  listas  de  control  de 
acceso  (ACL),  puertos  analizadores,  etc.  Se  dedican  a  instalarlas  en  la  red,  conectarles  un 
cable  y  punto,  quedando  con  los  valores  de  fábrica.  Un  potencial  atacante  podría  hacer  uso 
de  dicho  desconocimiento  para  tomar  el  control  del  dispositivo.  Si  este  tuviera  la  capacidad 
de  tener  puertos  de  monitorización,  se  le  estaría  facilitando  mucho  la  posibilidad  de  poder 
recoger  tráfico  al  que  de  ''forma  convencional”  no  tendría  acceso. 

Es  evidente  que  sin  este  despiste,  más  habitual  que  lo  que  sería  deseable,  un  atacante  no 
tendrá  acceso  de  forma  convencional  a  información  que  no  te  tenga  como  origen  o  destino. 
Sin  embargo  tal  y  como  está  argumentado  en  el  capítulo  anterior,  la  evolución  inicial  de 
la  tecnología  no  tenía  como  base  la  seguridad,  sino  que  será  un  proceso  reactivo  posterior 
el  que  la  desencadenará.  La  información  sigue  viajando  en  claro,  los  protocolos  iniciales 
no  establecían  lo  contrario,  simplemente  había  que  hacerse  con  ella  para  tratarla  y/o 
modificarla.  Aquí  entra  el  segundo  de  los  elementos  que  dan  título  a  este  capítulo:  Spoojing. 

En  el  sentido  estricto  spoqfing  identifica  todas  aquellas  técnicas  enfocadas  a  la  suplantación. 
Por  ejemplo  MAC  spoofing^  consiste  en  utilizar  la  dirección  física  de  otro  sistema  con 
objeto  de  suplantarlo.  Así  de  esta  forma  podría  obtenerse  una  dirección  IP  reserv'ada  en  un 
servidor  DHCP  {Dynamic  Host  Configuration  Protocoí),  acceder  a  una  red  WíFt  limitada 
a  determinadas  direcciones  físicas  o  bien  acceder  a  un  puerto  de  un  switch  que  permite  el 
acceso  a  una  MAC  concreta. 

Spoofing  por  lo  tanto  no  puede  considerarse  con  una  técnica  concreta,  sino  como  el 
conjunto  de  las  que  emplean  la  capacidad  de  suplantación  con  un  objetivo  nomiatmente 
malicioso.  Muchas  serán  las  técnicas  que  se  mencionarán  a  través  del  libro  ARP  Spoofing^ 
DNS  Spoofing  o  Spoofing  serán  algunas  de  las  significativas.  Prácticamente  en  cada 
capa  de  una  comunicación  tomando  como  referencia  la  pila  TCP/IP,  pueden  existir  técnicas 
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de  suplan tación.  Algunas  son  más  complejas  otras  más  simples  y  en  ocasiones  necesitarán 
una  combinación  de  otras  para  que  resulten  efectivas.  Prácticamente  cada  una  de  ellas 
puede  ser  evitada,  y  de  ello  se  tratará  también  en  el  libro,  pero  a  veces  el  desconocimiento 
o  el  coste  que  implica  hace  que  las  organizaciones  asuman  o  transfieran  el  riesgo. 

A  día  de  hoy  existen  numerosas  herramientas  que  hacen  uso  de  las  técnicas  de  suplantación 
como  base  para  la  realización  de  determinados  ataques.  No  son  ni  mucho  menos  recientes, 
al  igual  que  la  constancia  de  la  existencia  de  ataques  derivados  de  la  suplantación.  Un 
ejemplo  significativo  lo  constituye  un  fragmento  de  la  infonnación  recogida  en  el  RFC 
1 180  de  Enero  de  1991  y  que  se  transcribe  a  continuación, 

"Comicleraciones  de  seglaridad 

Hay  consideraciones  de  segundad  entre  el  conjunto  de  protocolos  TCP/IR  Para  muchas 
personas  estas  consideraciones  son  serios  problemas,  para  otras  no;  depende  de  los 
requerimientos  del  usuario. 

Este  tutorial  no  discute  estos  asuntos,  pero  sí  quiere  aprender  más  debe  comenzar  con  ei 
tema  de  ARP-spoqfing,  entonces  vea  la  sección  ''Consideraciones  de  Seguridad”  del  RFC 
¡122  para  tener  más  información.  ” 

En  1990  fecha  en  la  que  se  data  la  RFC  1122,  existía  ya  la  conciencia  de  ios  problemas 
derivados  de  la  seguridad,  pero  hay  que  tener  en  cuenta  que  la  definición  de  los  protocolos 
y  su  evolución  e  implantación  requiere  de  un  tiempo  generalmente  largo.  Basta  con  saber 
que  TCP/IP  se  fragua  con  décadas  de  antelación  a  estas  RFC,  para  entender  ios  aspectos  de 
la  '1i]’'seguridad  actual. 

Durante  estos  últimos  años  la  tecnología  ha  experimentado  una  evolución  y  crecimiento 
exorbitado.  La  tecnología  y  la  informática  se  han  hecho  indispensables,  y  esto  hace  creer 
que  el  ritmo  de  la  evolución  tecnológica  siempre  ha  sido  asi.  Sin  embargo  esto  no  es  ni 
mucho  menos  así. 

La  RFC  180  menciona  la  técnica  de  ARP  Spoofing  como  una  consideración  a  tener  en 
cuenta.  Prácticamente  un  capitulo  completo  del  libro  estará  orientado  a  la  misma,  pudiendo 
considerarse  la  técnica  base  para  la  realización  de  ataques  en  una  red  de  área  local  A  través 
de  la  técnica  de  ARP  Spoofing  se  podrá  reconducir  el  tráfico  entre  dos  entidades  a  través 
de  un  tercero.  No  hay  que  confundir  la  réplica  de  tráfico  con  la  reconducción  del  tráfico. 
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En  el  caso  de  los  puertos  de  monitorización  del  Switch  el  tráfico  de  A  llega  a  B  y  también 
se  replica  hacia  el  puerto  que  monitoriza  donde  estará  C.  En  el  caso  de  la  reconducción 
haciendo  uso  de  la  técnica  de  ARP  Spoofing  el  tráfico  de  A  llegará  primeramente  a  C  y  este 
lo  reconducirá  a  B.  Aunque  la  diferencia  parezca  sutil,  realmente  hay  un  abismo  entre  los 
dos  conceptos. 

Cuando  el  sistema  C  reciba  el  tráfico  ¿qué  le  impide  alterarlo  con  un  fin  determinado  antes 
de  renviarlo  a  B?  Nuevamente  un  nombre  cubre  este  segmento  dentro  de  los  ataques: 
Hijacklng.  Aunque  el  concepto  va  mucho  más  allá  que  la  simple  alteración,  secuestro  sería 
la  traducción  más  cercana,  aglutina  un  conjunto  de  técnicas  en  las  cuales  la  alteración  de 
los  datos,  sesiones,  comunicaciones  o  el  comportamiento  son  el  elemento  fundamental. 

Se  puede  decir  de  que  hay  más  técnicas  de  Hijackíng  que  de  Spoofmg^  aunque  muchas 
veces  pueden  incluso  llegar  a  confundirse.  El  espectro  de  ataques  de  secuestro  va  mucho 
más  allá  del  propio  concepto  de  comunicaciones. 

Un  ejemplo  claro  es  el  de  Browser  Hijackíng,  en  el  que  un  navegador  se  encuentra 
secuestrado  por  una  aplicación  maliciosa  de  tal  forma  que  la  información  que  recibe  ei 
usuario  viene  condicionado  por  parámetros  ajenos  al  mismo.  Por  ejemplo  la  modificación 
de  la  página  de  inicio,  o  bien  que  el  intento  de  acceso  a  una  determinada  página  tiene  como 
resultado  la  devolución  de  otra. 

Sin  embargo  también  hay  Htjacking  en  los  procesos  de  comunicación,  como  los  que  se 
dan  en  TCP/IP  cuando  se  secuestra  una  sesión  de  Telnet.  A  través  de  la  misma,  cuando  una 
comunicación  ha  sido  interceptada  y  reconducida  por  ejemplo  mediante  la  técnica  de  ARP 
Spoúfing,  el  atacante  podía  enviar  datos  diferentes  al  servidor  o  dispositivo  alterando  el 
propósito  inicial  de  la  comunicación. 

Hay  algo  simple  a  tener  en  cuenta,  un  atacante  que  quiera  realizar  alguna  acción  maliciosa  a 
través  de  la  red  deberá  encontrarse  en  modo  promiscuo.  Si  no  puede  procesar  la  información 
que  no  va  dirigido  hacia  él,  no  podrá  reconducirla,  ni  alterarla  para  su  conveniencia.  La 
técnica  de  snifjing  es  por  ío  tanto  la  base  de  todos  los  ataques  de  red.  No  hay  que  confundir 
entonces  Sniffing  con  Sníjfer,  puesto  que  mientras  que  el  primero  designa  una  técnica,  el 
segundo  habla  de  una  herramienta  y  no  por  ello  están  vinculados.  Tradicionalmente  el 
Sniffer  es  la  herramienta  que  muestra  por  pantalla  la  información  capturada  de  tal  forma 
que  pueda  ser  tratada  en  caliente  o  a  postenori,  Wíreshark  es  uno  de  los  más  significativos 
y  ampliamente  empleados. 
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Fig.  33.-  Wirexhark. 


Wireshark  ha  evolLicionado  significativamente  con  el  paso  del  tiempo.  Inicialmente 
constituía  una  herramienta  donde  exclusivamente  se  volcaba  la  información  que  llegaba  al 
adaptador.  Ahora  presenta  potentes  filtros  para  cribar  la  información.  La  siguiente  imagen 
muestra  el  sistema  de  filtros  que  permiten  aislar  una  comunicación  concreta. 


Fig,  3,4.-  Filtrado  con  Wireshark. 
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También  es  factible  la  reconstrLicción  de  la  comunicación  completa  de  todo  el  tráfico, 
mediante  el  seguimiento  a  los  mensajes  intercambiados  durante  la  conversación  entre 
el  cliente  y  el  servidor  que  ban  sido  capturadas  por  ei  sniffer.  Un  ejemplo  de  esto  se 
puede  observar  en  la  siguiente  imagen,  fimto  de  una  captura  de  tráfico  HTTP,  en  la  que 
se  ha  utilizado  la  funcionalidad  de  Wireshark  llamada  Follow  TCP  stream  para  hacer  un 
seguimiento  completo  de  una  conversación. 


Fig.  3.5.‘  Reconsirucción  de  una  comuíiicación  con  Wireshark. 


Como  se  puede  apreciar  en  la  imagen  anterior,  se  imprime  en  un  solo  finjo  los  mensajes 
del  cliente  -  GET  en  este  ejemplo  concreto  -  y  los  del  servidor  -  en  este  caso  una  respuesta 


HTTP  200-. 


El  tráfico  reconstruido,  puede  ser  guardado  de  ta!  forma  que  podría  llegar  a  abrirse  con 
alguna  aplicación  especifica  para  la  información  capturada. 


Capitulo  ///■  Sniffing,  Spoofingy  Haijacking. 
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Fig.  3.6  -  Ret^üper^ción  de  fichero  con  Wireshark. 


Pero  no  es  necesario  tener  una  herramienta  puramente  smffer  a  nivel  de  interface  de  usuario, 
para  aplicar  las  técnicas  de  Spoofing  o  Hijackíng.  Esencialmente  estas  últimas  harán  de 
filtro  de  la  información  mostrando  para  ello  sólo  lo  que  es  necesario  para  que  la  aplicación 
de  la  técnica  sea  efectiva,  cribando  el  resto  de  datos  que  de  una  u  otra  forma  son  superfinos 
o  innecesarios  para  el  objetivo. 

Este  hecho  suele  generar  confusión  puesto  que  muchas  herramientas  aparentan  capturar  sin 
ser  Smffer  y  en  esencia  es  así.  Con  el  modo  promiscuo  activo  el  sistema  tendrá  la  capacidad 
de  interpretar  tráfico  no  dirigido  hacia  él.  Si  la  herramienta  es  capaz  de  diferenciar  el  tráfico, 
cribarlo  y  controlarlo  cumple  con  el  objetivo  fundamental.  Pero  en  esencia  esto  también  es 
lo  que  hace  un  Sniffer. 

Una  herramienta  como  Caín ampliamente  conocida  y  una  de  las  mejores  herramientas 
de  ARP  Spoofing  y  recuperación  de  contraseñas  para  entornos  Windows,  en  su  proceso 
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de  instalación,  requiere  de  la  instalación  de  JVinPcap.  Caín  y  Abel  utilizan  H^inPcap  para 
habilitar  el  modo  promiscuo  y  las  funcionalidades  que  así  se  proporcionan  para  filtrar  el 
tráfico  recogido  a  través  de  la  aplicación. 


WinPMp  Imtaltntion  [W¡ 


V/ARNiMG  !>!  THst  tnoafam  uí*s  the  púcítoL  dirvaí  that  coHWS  Mttí 
WinPcap  v4 1,2  evíjjflhie  s(  íww.wmpcap  ffa 

Do  want  to  mítal  iHo  packot  drivw  tioiw  ? 


Fig.  3.7.-  Instalación  de  Caín  y  Abel  con  WinFeap. 

Las  herramientas  de  Spoofing  y  ¡fijacking  al  contrario  que  las  de  snlffing,  deben  tener 
siempre  desde  el  punto  de  vista  de  una  empresa,  connotaciones  negativas.  Sus  acciones 
son  particularmente  dañinas  en  determinados  escenarios,  pudiendo  en  esencia  acceder  a 
información,  servicios  o  cuentas  sensibles  para  la  información,  pero  también  porque  no, 
suplantar  a  personas  o  sistemas  dentro  de  la  red* 

Debido  a  esta  problemática,  a  lo  largo  también  de  los  años  se  han  ido  aplicando  diferentes 
técnicas  y  tecnologías,  con  objeto  bien  de  evitar  o  mitigar  los  ataques.  Los  resultados  han 
sido  más  o  menos  efectivos,  algunos  hasta  ingeniosos.  En  ocasiones  se  mitiga  el  problema, 
en  otras  deja  de  ser  preocupante.  Por  ejemplo  para  mitigar  el  ARP  Spoofing,  puede 
impedirse  el  ataque  o  bien  cifrar  la  infonnación  que  viaja.  En  esencia  en  el  segundo  caso 
no  se  evita  el  ataque  pero  se  previene  que  el  atacante  pueda  analizar  la  información*  ¿Qué 
es  más  efectivo?  Inicial  mente  el  primero  puede  ser  más  eficaz,  pero  evidentemente  ARP 
Spoofing  no  es  la  única  fonna  de  hacer  ataques.  El  segundo  obvia  los  ataques  y  se  centra 
en  proteger  la  información.  Ambos  pueden  ser  válidos  y  serán  las  empresas  las  que  escojan 
su  estrategia. 
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No  obstante  hay  que  tener  presente  que  pueden  desviarse  muchos  esfuerzos  a  acciones 
que  no  tienen  sentido*  Reciclarse  es  importante  y  tener  conciencia  de  lo  que  pasa  aún  más. 
A  veces  se  focaliza  una  determinada  defensa  contra  un  ataque  o  mecanismo  concreto  y  al 
paso  del  tiempo  esta  medida  ya  tiene  su  contra  réplica  o  bien  no  es  tan  efectiva  como  lo  era 
originalmente.  La  tecnología  evoluciona  y  la  seguridad  a  su  par. 

Hace  años  se  hicieron  populares  las  herramientas  anüsníffer.  Estas  tenían  como  objetivo 
detectar  la  presencia  de  sistemas  en  modo  promiscuo.  La  base  fundamental  consistía  en 
enviar  tramas  falsas  que  no  deberían  ser  procesadas  por  ninguna  máquina  de  la  red.  En 
caso  de  que  una  máquina  respondiera  sería  síntoma  de  que  estaba  trabajando  en  modo 
promiscuo  puesto  que  respondería  a  una  petición  que  no  le  correspondería* 

Evidentemente  estas  técnicas  tienen  un  fundamento  técnico  débil,  puesto  que  bastaría  con 
el  simple  hecho  de  programar  al  sistema  malicioso  a  responder  ante  peticiones  dirigidas 
específicamente  a  él  (por  lo  tanto  sin  implicar  al  modo  promiscuo),  o  enviar  lo  estrictamente 
necesario  en  un  entorno  controlado*  Era  imiecesario  responder  ante  peticiones  que  no 
debían  ser  procesadas.  Si  una  empresa  contaba  con  una  de  estas  herramientas  podía  estar  en 
la  falsa  creencia  de  que  ningún  equipo  se  encontraba  en  modo  promiscuo  cuando  realmente 
esto  no  era  así.  Este  es  un  hecho  innegable  de  falsa  percepción  de  la  seguridad. 

Las  heiramientas  de  los  atacantes  se  readaptan^  aparecen  nuevas  técnicas  de  evasión  o 
bien  se  idean  nuevos  elementos  de  ataque.  La  seguridad  se  debe  considerar  igualmente  en 
este  sentido*  Debe  ser  adaptativa,  no  puede  plantearse  mantener  sistemas  de  defensa  de 
principios  del  2000  ante  ataques  o  técnicas  actuales.  Hace  años  el  firewail  prevenía  frente 
a  intrusiones  que  procedían  del  exterior*  Pero,  ¿qué  pasa  si  el  enemigo  está  ya  en  casa?, 
por  ejemplo  un  malware  que  realiza  una  conexión  HTTPS  de  tipo  reversa  y  genera  el  canal 
de  comunicaciones  perfecto  para  que  el  atacante  controle  de  fonna  externa  un  sistema 
interno*  Desde  este  sistema  controlado  el  atacante  podría  lanzar  ataques  de  suplantación  o 
de  secuestro  de  sesiones  dentro  de  la  red,  sin  ni  siquiera  tener  presencia  física  real. 

El  ataque  a  día  de  hoy  no  es  más  fácil  que  hace  años,  sino  que  ha  evolucionado,  cuando 
muchas  organizaciones,  siguen  pensando  en  axiomas  demasiados  obsoletos.  Los  ataques 
en  redes  de  datos,  llevan  dándose  desde  hace  mucho  tiempo,  han  mejorado  y  evolucionado. 
Las  herramientas  hacking  ponen  al  alcance  de  muchos  cosas  que  en  los  años  90  estaban 
destinada  a  auténticos  especialistas. 
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Actualmente  muchos  usuarios  aplican  técnicas  de  ataque  complejas,  porque  las  herramientas 
son  simples.  Hacer  ARP  Spoofing  con  Caín  y  Abel  es  relativamente  sencillo,  entender  por 
qué  a  veces  funciona  y  otras  no,  o  bien  por  qué  se  da  un  determinado  comportamiento, 
requiere  una  mayor  comprensión.  A  lo  largo  de  los  siguientes  capítulos  se  va  a  hablar  de 
diferentes  técnicas  de  Sniffing,  Spoofing  y  Hijackíng,  mostrando  el  por  qué  suceden.  Quizás 
aunque  no  sea  necesario  para  atacar,  puesto  que  el  "'botón  gordo”  de  tal  herramienta  lo  hace 
sencillo,  si  será  muy  necesario  para  saber  detectarlo,  contrarrestarlo  o  evitarlo. 

Decía  Sun  Tzu  en  El  arte  de  la  guerra:  "'‘conoce  a  tu  enemigo  y  conócete  a  ti  mismo;  en 
cien  batallas,  nunca  saldrás  derrotado.  Sí  eres  ignorante  de  tu  enemigo  pero  te  conoces 
ü  ti  mismo,  tus  oportunidades  de  ganar  o  perder  son  las  mismas.  Si  eres  ignorante  de  tu 
enemigo  y  de  ti  mismo,  puedes  estar  seguro  de  ser  derrotado  en  cada  batalla.  “ 


Capitulo  IV.  Atacando  por  capas 


39 


Capítulo  IV 
Atacando  por  capas 


Alacar  una  red  de  datos  es  una  conjunción  de  paciencia,  pericia  y  suerte.  Paciencia  para 
localizar  los  objetivos,  pericia  para  aplicar  las  técnicas  y  herramientas  adecuadas  y  la  suerte 
para  estar  en  el  lugar  adecuado  y  sobre  todo  “que  no  te  pillen”.  En  muchas  ocasiones  las 
diferentes  herramientas  de  las  que  se  denominan  “botón  gordo”  hacen  demasiado  ruido  y 
basta  un  sistema  simple  de  detección  de  intrusiones  para  detenninar  que  se  está  produciendo 
un  ataque. 

El  planteamiento  det  ataque  se  basa  fundamentalmente  en  analizar  las  capas.  No  es  objetivo 
del  libro  como  ya  se  habló  de  forma  previa  que  sea  un  memorándum  de  OS  1  o  TCP/IP,  pero 
es  fundamental  entender  determinados  conceptos  para  saber  por  qué  pasan  en  ocasiones 
algunas  cosas. 

Por  ejemplo  un  atacante  que  quiera  obtener  credenciales  de  un  usuario  de  la  organización 
puede  emplear  múltiples  recursos  para  lograrlo.  Lo  mismo  pedírselos  directamente  podría 
funcionar  y  seria  lo  más  simple,  pero  no  parece  muy  elegante,  teniendo  en  cuenta  que 
pueden  utilizarse  un  conjunto  de  argucias  más  enrevesadas.  Por  ejemplo  si  la  organización 
tiene  una  intranet  donde  autenticarse,  se  podría  replicar  esta  en  otro  sistema  controlado 
por  el  atacante.  La  víctima  llegaría  a  ella  mediante  de  una  resolución  de  nombre  maliciosa 
tras  aplicar  la  técnica  de  DNS  Spoofing,  que  se  habría  apoyado  previamente  en  un  ARP 
Poisoning,  consiguiendo  así  que  el  usuario  facilite  gentilmente  sus  credenciales.  La 
resolución  es  la  misma  pero  la  segunda  parece  más  compleja  ¿por  qué? 

En  esencia  no  porque  las  técnicas  o  recursos  anteriormente  citados  sean  muy  complejos  de 
manejar,  sino  porque  en  ocasiones  es  muy  complicado  dar  con  la  víctima.  Basta  pararse 
a  pensar  en  cómo  un  atacante  sería  capaz  de  localizar  la  MAC,  dirección  IP  o  nombre  de 
equipo  de  la  persona  de  la  que  desea  algo,  en  una  empresa  con  más  de  500  equipos.  La 
respuesta  es  “con  paciencia  y  con  mucho  cuidado”.  El  número  de  teléfono  hubiera  sido 
más  fácil,  se  lo  preguntas  a  cualquiera  y  no  resulta  sospechoso.  A  veces  obtener  un  dato 
como  el  nombre  de  equipo  resulta  más  simple  cuando  estos  tienen  una  asociación  directa 
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con  la  persona  o  el  rol  que  ocupan,  pero  en  muchas  circunstancias  los  nombres  no  sugieren 
nada...  o  sí.  La  experiencia  o  la  menle  maliciosa  del  atacante  en  este  sentido  juegan  a  su 
favor.  Hacer  un  ataque  aleatorio  en  la  red  de  una  empresa  puede  resultar  sencillo,  hacerlo 
concretamente  frente  a  un  usuario  requiere  por  regla  general  más  tiempo  y  conocimientos. 

Resulta  claro  que  con  tiempo  y  la  obtención  de  una  cuenta  débil,  podría  escanearse  la  red 
y  si  por  ejemplo  el  atacante  se  encuentra  ante  un  escenario  puramente  Microsoft^  podrían 
llegar  a  saber  las  cuentas  de  usuario  validadas  en  cada  máquina.  Con  estos  datos  el  ataque 
de  Spoqfing  sería  más  eficaz,  aunque  habría  habido  una  inversión  de  tiempo  previo  para 
llegar  a  ello.  En  este  punto  se  llega  a  la  conclusión  que  haber  descolgado  el  teléfono  y 
haberse  hecho  pasar  por  el  departamento  de  soporte  técnico  hubiera  sido  más  fácil,  eso  sí, 
no  tan  elegante. 

En  ocasiones,  y  sobre  todo  en  las  primeras  experiencias,  no  hay  nada  tan  desolador  como 
cuando  el  auditor  que  inicia  un  análisis  de  seguridad  interna  en  modo  caja  negra  y  tras 
conectar  su  ordenador  a  la  red,  obtiene  como  dirección  IP  una  de  tipo  APIPA  (asignada 
automáticamente  por  el  cliente  DHCP,  cuando  no  obtiene  respuesta  de  un  DHCP). 
Momento  de  tensión  y  todo  un  mundo  por  descubrir  tras  arrancar  un  sníjfer^  ¿cuáles  son 
las  direcciones  IP?  ¿Por  qué  hay  broadeast  de  tres  segmentos  diferentes  supuestamente 
diferentes?  Las  tramas  ARP  no  tienen  sentido.  Es  cierto  que  en  muchas  circunstancias 
la  experiencia  de  horas  y  horas  analizando  tramas  con  una  herramienta  como  Wireshark,, 
pennite  que  ese  inicio  sea  finalmente  una  interpretación  más  o  menos  rápida  y  cercana  a  la 
realidad.  Pero  con  constancia  se  llega  a  las  conclusiones  acertadas. 

Una  vez  que  se  tiene  más  o  menos  claro  la  dirección  IP  a  utilizar  o  bien  la  ha  dado  el 
DHCP,  y  por  lo  tanto  se  ha  ganado  tiempo,  llega  la  hora  de  analizan  El  comienzo  del 
análisis  de  una  red  siempre  debe  ser  el  de  sus  cimientos,  la  electrónica  de  la  red.  A  partir  de 
ahí  todo  consiste  en  determinar  los  diferentes  protocolos  y  servicios  que  podrán  a  la  larga 
determinar  las  técnicas  de  ataque  a  emplear. 


4.1.-  Identificación  y  ataques  a  dispositivos  de  red 

Determinar  qué  electrónica  de  red  existe  en  una  red  proporciona  infonnación  muy 
interesante.  Por  lo  pronto  permite  conocer  de  antemano  las  posibilidades  que  en  cuanto  a 
contramedidas  puede  emplear  la  organización.  También  de  su  configuración  dice  lo  mucho 
o  poco  que  una  organización  dedica  a  la  seguridad. 
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Como  ya  se  comentó  previamente  no  son  pocos  los  escenarios  en  los  que  los  administradores 
se  dedican  a  poner  Switch  y  pinchar  más  y  más  cables.  Seguramente  no  exista  la  conciencia 
del  problema  ni  tampoco  de  las  soluciones  que  se  ofrecen.  En  muchas  circunstancias  sí 
existe  esa  preocupación,  pero  no  es  completa.  Muchos  modelos  de  dispositivos  permiten 
una  administración  en  modo  gráfico  y  otro  en  modo  comando.  Esta  segunda  aunque  menos 
intuitiva  y  amigable  es  más  potente  y  pemnite  llegar  a  configuraciones  que  no  se  encuentran 
a  veces  disponibles  a  través  del  interface  gráfico.  Por  ejemplo  determinados  modelos  de 
dispositivos  Switch  de  la  marca  3Com,  mantienen  además  del  usuario  Admin^  otros  tres 
usuarios.  Dos  de  ellos  son  privilegiados,  con  contraseñas  altamente  predecibles.  Este  hecho 
es  particulannente  peligroso,  puesto  que  la  administración  de  las  mismas  se  debe  realizar 
a  ti'avés  del  modo  comando. 

Mantener  un  sistema  con  configuraciones  por  defecto  ofrece  demasiadas  opciones  a  un 
atacante  y  permite  que  este  aproveche  las  capacidades  del  mismo  en  su  propio  beneficio, 
como  por  ejemplo  reconducir  el  tráfico  a  su  puerto. 
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PÉg.  4.1.-  Claven  pmletemiínadas  de  dispositivos. 


Este  hecho  no  es  solamente  válido  para  Switch,  sistemas  de  almacenamiento,  de  copia 
de  seguridad  o  impresoras  de  red  son  también  dispositivos  que  pueden  ser  accesibles 
fácilmente,  si  no  se  ha  tenido  un  mínimo  cuidado  en  protegerlos.  En  este  sentido  antes  de  la 
puesta  en  marcha  de  un  nuevo  dispositivo,  un  administrador  o  responsable  de  red  debería 
tomarse  su  tiempo  para  analizar  que  tiene  entre  manos.  Conocer  qué  configuración  trae  de 
fábrica  y  en  qué  medida  debe  modificarlo  para  no  tener  una  incidencia  de  seguridad  debería 
ser  una  máxima.  Muchas  organizaciones  dedican  esfuerzos  en  fortificar  sus  sistemas  y  tener 
correctamente  actualizados  los  servidores  y  puestos  de  trabajo  pero  no  hacen  lo  mismo  con 
los  dispositivos  de  red. 


42 


Ataques  en  redes  de  datos  lPv4  e  iPv6 


Hay  que  tener  en  cuenta  que  un  Switch  es  hardware,  pero  también  suele  contar  con  un 
Kemeil,  a  veces  con  un  motor  web,  un  servicio  de  SNMP  {Simple  Network  Management 
Protocol)  y  otro  gran  número  de  elementos.  Si  no  se  tiene  cuidado  en  ello  podría  llegar 
a  constituirse  un  verdadero  problema  de  seguridad.  Hay  que  tener  en  cuenta  que  las 
vaiinerabilidades  afectan  a  todos  los  niveles  del  software,  incluido  el  correspondiente  al 
que  se  ejeeuta  en  los  sistemas  de  red*  Sirva  de  ejemplo  la  siguiente  imagen  correspondiente 
a  vulnerabilidades  de  dispositivos  Cisco. 
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http :  //WWW  .secuíityf  Dcus  xoni/bndl/302  9  5 

Múltiple  Cisco  Products  CVE-2011-2?3fl  Remóte  Code  Executíon  VulrterabilitY 

2011-10-18 

http :  // w  w  w.secu  r  ityf  Qcu  s . co  m/bid/4  9&2  7 

Cisco  IOS  Smart  Instait  Remóte  Code  Executíon  Vuloerability 

30lM0'll 

http  í  // w  w  w,  securityfocu  s*com/bi<V  28 

Cisco  Unified  Presence  and  Jabber  XCP  XML  Bomb  Deniat  of  Service  Vulnerablllty 

2011-10-11 

http : // w  w  w .  seojrityf  qcu  i;  *qofTi/bidi/4  90 1 9 

Múltiple  Cisco  Products  SunltPC/ILS  Inspections  Múltiple  Remóte  Dental  of  Service  Vulnera bitities 

2011-10-05 

http  1  // w  w  w .  s  ecuñtyfocu  5-com/bid/499  5 1 

Cisco  ASA  5500  Series  MSN  IM  Inspectiori  (CVE-  2011-  33D4}  Denial  of  Service  Vuloerability 

201MQ  05 

http :// w  w  w.  secuntvfocüs.  com/bid/499  S  2 

Cisco  Ftrewall  Services  Module  Syslog  Message  De  nial  of  Service  Vulnerabllity 

2011-10-05 

http ://  WWW.  securityfíx:us,coiT>/bid/499  53 

Cisco  NetWork  Admlsslon  Cúnm)l  {CVE- 201 1-3305)  Direclory  Traversa!  Vulnerabilíty 

2011-10^05 

http ://  WWW .  Sí!cunt¥focus,com/bkl/49954 

Cisco  Firewaif  Services  Module  Authentication  Proxy  Remóte  Dental  of  Service  Vulnerabilíty 
2011-20-05 

http  ://w  w  w .  £ecijri(tyfoajs.cCMTi/bid/499  55 


Fig.  4*2.- Vulnerabilidades  de  Cisto. 


Un  atacante,  explotará  todas  las  posibilidades  existentes  y  cuanto  menor  sea  el  margen  que 
se  ¡e  ofrece  mucho  mejor  Como  atacante  deberá  conocer  su  posición  con  respecto  a  la  red 
y  aquí  es  muy  importante  cerrar  la  máxima  visión  posible.  Como  se  verá  más  adelante, 
detenninados  tipos  de  ataques  solo  son  factibles  dentro  de  un  segmento  físico,  esto  implica 
que  si  el  atacante  se  encuentra  dentro  de  una  VLAN  determinada,  no  debería  poder  llegar 
a  cabo  su  ataque  más  allá  de  la  misma.  Sin  embargo  si  tiene  acceso  a  la  electrónica  de  red, 
podría  llegar  a  alterar  esa  posición* 
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Hay  que  aprovechar  todas  las  ventajas  que  aporta  un  dispositivo  de  red,  por  muy  compleja 
que  pueda  parecer  Tmplementar  una  VLAN  a  nivel  de  Switch  no  es  algo  complejo  aunque 
tradicionalmente  siempre  inspira  miedo  a  todos  aquellos  ufanos  en  la  materia.  Sin  embargo 
constituye  un  aliado  estratégico  para  luchar  contra  los  ataques  en  redes  de  datos.  En  vez 
de  eso  muchas  empresas  se  ven  tentadas  a  realizar  esa  segmentación  a  nivel  lógico  puesto 
que  parece  más  fácil.  Es  decir  una  única  VLAN  y  utilizando  diferentes  direcciones  IP  para 
separar  departamentos  y  servicios.  Aunque  pueda  parecer  descabellado,  se  da  en  muchas 
circunstancias  y  es  tan  simple  de  darse  cuenta  como  abrir  un  sniffer  y  encontrarse  con 
tráfico  broadeasty  que  indican  múltiples  redes  lógicas  en  un  mismo  segmento  físico. 
El  atacante  solo  tendrá  que  tomar  nota  y  cambiarse  la  IP  para  ir  saltando  de  red  en  red.  Si 
esa  misma  circunstancia,  segmentación  lógica,  se  ve  acompañada  por  una  segmentación 
física,  el  vector  de  ataque  se  reducirá  considerablemente. 

En  ocasiones  ese  desconocimiento  de  la  seguridad  o  la  misma  despreocupación,  hacen 
que  las  organizaciones  faciliten  las  cosas.  Por  ejemplo  dejar  implementado  el  protocolo 
SNMP  cuando  no  se  está  haciendo  uso  del  mismo,  permite  que  alguien  pueda  obtener 
información  valiosa  del  dispositivo.  Existen  numerosas  aplicaciones  que  permiten  realizar 
esta  operación  y  de  ellas  podría  destacarse  SNMPWalk. 


F^íé  Eí;:1  n-c-ü 

fl.  -Os  -C  PíJMiú  1  1  íi, 

^0^  ::r::  1  ^  ECEUvAFF 

:opYí“'4^'  Ki  \ 

Cctfíipi  A 

eí.  LIO .  ^  -  OIA:  -:í3vL- 

■  tí  “ 

t;  ”  .  ' rOi\t 
>  VSLOC¿ltli;‘í’i ,  -  j  -  : 

.•7^SÉ?rv,:r-- ,3  INTEGE^; 

^  ^■1-- 

^  I 


Fig.  4.3  -  SMPWaIk  en  acción. 


O  también  recuperar  ficheros  de  configuración  completos,  como  la  posibilidad  que  ofrece 
Caín  y  Abel  a  través  de  su  funcionalidad  completa  de  Cisco  Confíg  Downloadcr/Uploader 
que  permite  en  una  conjunción  de  SNMP  y  TFPT  {Trivial  File  Transfer  Proíoco¡\  con 
compilaciones  OLD-Oóco-System_MIB  o  C/óco-Config  Copy-MIB,  recuperar  el  fíchero 
running-config. 
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Para  la  realización  del  ataque  es  necesario  además  de  una  mala  configuración  del  dispositivo 
a  nivel  de  seguridad,  la  no  aplicación  de  ACL  para  acceso  SNMP  o  TFTP,  y  será  necesario 
conocer  o  acertar  con  la  comunidad  SNMP.  De  forma  predeterminada  suelen  utilizarse,  las 
comunidades  Public  o  Prívate,  pero  también  el  nombre  de  la  empresa.  En  ocasiones  hacer 
uso  de  la  ingeniería  social  pueden  dar  resultados  significativos. 


!  ^  i 

,  mth  «ehi  ntla  i 

'  +  ^  ,  u  1 

O  1 1 

^  PecadtTs  I  ^  NetWork  Sniffgf  |ia/  Cracker  Tra¿.efQute  lia  CCPülT  WiíelBt  1^  Qutty  I 


Timestamp 


ÍPAddress 


SNMP  R/W  Community  ]  Ftltname 


Cisco  Con^g  Downtoader 


i-Device  Hosirame  ^  IP  AdckKs- 


|r72.ai  D,2Q0 


SNMP  ReadA^rite  ConrtrñiJiriilyi-- 


Ipublic 


Bolocd- 


DK 


U 


Cancel 


Fig.  4.4,-  Recuperación  del  fichero  de  configuracjón. 


Fig,  4,5.*  Fichero  de  configuración. 
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Tras  proporcionar  los  datos  correspondientes,  incluyendo  la  dirección  IP  de  conexión  con 
el  dispositivo,  se  podrá  recuperar  el  fichero  de  configuración  del  mismo,  podiendo  ser 
utilizado  para  obtener  las  claves  con  tas  que  acceder  al  mismo. 

Si  bien  es  cierto  que  este  tipo  de  ataque  requiere  de  una  serie  de  condiciones:  configuraciones 
débiles,  sistemas  antiguos,  falta  de  actualizaciones,  etc.,  no  existe  una  norma  común  a  la 
hora  de  establecer  la  seguridad  de  los  mismos.  Se  asume  de  forma  predeterminada  que 
estos  dispositivos  cumplen  su  funcionalidad  y  por  el  hecho  de  ser  “hierro”  no  tiene  nada 
que  ver  con  el  asunto  de  la  seguridad. 

El  siguiente  ejemplo  muestra  las  diferencias  en  cuanto  a  criterios  de  la  seguridad  que  pueden 
existir.  Se  comentaba  en  el  anterior  capítulo  que  los  Svt'itch  mantienen  una  base  de  datos 
con  el  conjunto  de  MAC  asociados  a  los  puertos  del  mismo  denominada  CAM  {Contení 
addressable  memory)  Table.  Si  alguna  trama  tiene  como  destino  una  dirección  física  que 
no  está  en  la  base  de  datos,  podrían  suceder  varias  posibilidades,  que  el  Switch  intente 
localizarlo  por  si  mismo  o  bien  que  la  información  se  retransmita  por  todos  los  puertos  o 
que  ésta  sea  rechazada.  Nuevamente  la  condición  como  ya  se  expuso  anteriormente  es  qué 
hará  im  dispositivo:  funcionalidad  frente  a  ¿seguridad? 


f  ^  ^  ^  ^  * 

I  fjie  tltíst  Viev;  iidp 

■  '  '  ó;:  :  z  ir  n<tU  C'í 
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994Ü914C9Í  Vir.  jVI 
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Ií)'163ri9í3)  vítí  517 

ÍÍ8  r  55n  4 :  7V:  *33  :  ^5  Ot^.Cí  C1.5ÍÍD67  >  7i.  tí  .tí  .ü  ,  :  5 

■  -  5L7 
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Fig,  4,6.-  Aplicación  matT^para  ei  desborda  míenlo  de  la  tabla  CAM. 

La  base  de  datos  que  puede  mantener  un  Switch  depende  fundamentalmente  de  sus 
earacterísticas,  los  hay  con  menos  posibilidades  y  otros  con  mayores.  Este  aspecto  entre 
otros  es  el  que  marca  una  diferencia  cuantitativa,  tanto  tecnológica  como  económica. 
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Existe  por  lo  tanto  la  opción  de  intentar  desbordar  dicha  tabla  para  que  el  comportamiento 
del  Switch  no  sea  el  deseado.  Si  se  superan  los  límites  de  almacenamiento  de  información 
existente  en  la  tabla,  podría  ocurrir  que  tráfico  legítimo  fuera  renviado  por  todos  los  puertos 
Si  la  información  de  la  dirección  MAC  destino  no  se  encuentra  en  k  tabla.  La  aplicación 
maco/^permite  explotar  este  problema,  enviando  tramas  con  diferentes  direcciones  físicas 
con  objeto  de  desbordar  la  tabla  CAM  de  un  dispositivo. 

Existen  como  no,  un  múltiple  número  más  de  posibilidades  para  explotar  la  funcionalidad 
de  una  red  en  busca  de  acciones  maliciosas.  Aquí  se  han  mostrado  alguna  de  ellas,  pero  las 
posibilidades  son  múltiples. 

No  debería  cerrarse  este  punto  sin  hacer  mención  a  una  aplicación  muy  interesante 
denominada  Yersinia  {http://w\\^v.yers¡níaM€tl\  que  permite  analizar  y  explotar  múltiples 
funcionalidades  o  debilidades  de  una  red.  Alterar  el  comportamiento  del  protocolo  STP 
{Spanning  Tree  Protocol)^  modificar  las  VLAN  de  un  dispositivo  o  cacharrear  con  los 
más  modernos  sistemas  802, IQ  y  802, IX  son  algunas  de  las  características  que  aporta.  Se 
mostrará  en  el  capítulo  correspondiente  de  VEAN  algunas  de  las  funcionalidades  aportadas 
por  esta  aplicación. 


4.2.-  Ataque  en  la  capa  de  enlace 

La  capa  de  enlace  constituye  un  elementa  fundamental  en  la  comunicación  dentro  de  las 
redes  de  área  local.  Hay  que  tener  presente  que  casi  toda  la  infonuación  sensible  y  crítica 
que  se  maneja  en  una  empresa,  lo  hace  desde  dentro,  con  destino  a  otros  sistemas  internos 
o  a  otros  externos.  Es  por  ello  que  la  seguridad  interna  es  clave  a  día  de  hoy.  Ya  se  comentó 
que  las  barreras  externas  c  internas  se  han  acercado  bastante.  Las  redes  inalámbricas  o 
atacantes  que  en  modo  reverso  controlan  sistemas  del  interior,  permiten  que  una  amenaza 
que  afecta  a  los  medios  internos  sea  efectiva  de  forma  externa  y  con  una  cierta  capacidad 
de  enmascaramiento. 

Nóminas  que  van  a  una  impresora,  acceso  a  una  intranet  por  personal  de  RRHH  o  los 
ficheros  de  orientación  de  negocio  almacenados  en  el  servidor  constituyen  elementos  que 
en  el  dia  a  día  de  una  organización  son  habituales  y  todas  dependen  de  la  red.  A  menudo 
se  fortifican  determinados  ser\  icios,  pero  se  discriminan  aspectos  tan  fundamentales  como 
que  la  información  que  transita  por  la  red  no  ofrece  ninguna  seguridad  de  forma  inicial. 
TCP/IP  no  proporciona  mecanismos  nativos  para  el  cifrado  de  la  infarmación.  Protocolos 
seguros  de  capa  de  aplicación  o  TPsec,  ofrecen  esas  garantías,  pero  son  posteriores  a  los 
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ftindamentos  base  con  tos  que  se  diseñó  el  stack  de  protocolo  y  motivados  finalmente  por 
la  necesidad  de  aplicar  seguridad. 

El  ataque  por  antonomasia  y  que  ha  sido  mencionado  de  forma  previa  lo  constituye  el 
de  ARP  Poisonig.  Este  basa  su  funcionalidad  en  la  propia  funcionalidad  del  protocolo 
ARP.  En  los  proceso  de  comunicación  que  se  establecen  en  TCP/IP,  se  hacía  necesario 
realizar  la  unión  entre  las  capas  puramente  lógicas  (3  superiores)  con  las  físicas.  Para 
ello  era  indispensable  combinar  de  una  forma  u  otra  el  valor  de  identificación  en  la  capa 
3  (dirección  IP)  y  en  la  capa  2  (dirección  MAC).  De  esta  forma  un  paquete  podría  ser 
identificado  completamente  y  encaminado  correctamente  a  través  de  lodos  los  niveles 
de  la  comunicación.  Los  dispositivos  de  capa  2  (conmutadores)  y  3  (routers)  no  tendrían 
problemas  para  hacer  llegar  a  su  destino  las  tramas.  El  protocolo  encargado  de  esa  tarea  de 
relacionar  IP  y  MAC  es  ARP.  Las  especificaciones  de  este  protocolo  datan  del  año  1 982, 
siendo  definidas  a  través  de  la  RFC  826.  La  idea  fundamental  de  este  protocolo  consiste 
en  la  obtención  de  la  dirección  física  de  un  sistema  conociendo  su  dirección  IP,  aunque 
también  es  factible  el  proceso  inverso  haciendo  uso  del  protocolo  RARP  {Reverse  ARP). 
Para  la  obtención  de  dicha  información  se  envía  una  petición  de  tipo  AliP  Request  al  que  le 
corresponderá  una  petición  de  tipo  ARP  Reply  en  caso  de  respuesta  afirmativa. 


Fig.  4,7,-  Trama  ARI*  Requerí. 
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Las  definiciones  de  funcionalidad  del  protocolo  ARP  establecían  que  cualquiera  que 
tuviera  la  respuesta  podría  ofrecerla  y  por  lo  tanto  el  solicitante  debería  aceptarla.  Es  por 
ello  que  un  equipo  podría  aceptar  una  respuesta  de  tipo  ARP  Reply  de  un  equipo  que  no 
correspondiera  con  la  IP  solicitada.  También  un  sistema  podrá  aceptar  una  petición  de  tipo 
ARP  Reply,  sin  que  hubiera  existido  una  petición  de  tipo  ARP Request  previa.  Está  claro  que 
las  especificaciones  fueron  fundamentadas  en  un  entorno  de  confianza  completa.  Si  alguien 
sabe  alguna  cosa  mejor,  que  lo  comunique,  ante  una  respuesta  rápida  la  comunicación  será 
más  efectiva.  El  engaño  no  se  encontraba  entre  las  opciones  barajadas. 


ARP  además  de  ser  un  protocolo  de  resolución,  también  es  conocida  como  la  aplicación 
local  donde  realizar  la  consulta  de  las  resoluciones  obtenidas.  Hay  que  tener  presente  la 
importancia  de  la  resolución  de  IP  y  MAC,  si  esta  no  fuera  consecuente  la  comunicación 
no  sería  efectiva.  Basta  un  simple  ejemplo,  si  se  introduce  una  información  errónea  en  la 
tabla  local  ARP  la  comunicación  no  será  efectiva. 


C :  \W  INDO 3  2\cm  d . 


C:S>pifig  192-1GB-0>1 

Haciendo  ping  a  192..1&B.0. i  con  32  de  datos: 

.^■íspuesta  desde  192_1BB_0_1:  bytes-32  tien>pü-lins  TIL-128 
■Respuesta  desde  192.1&B.0.Í:  b<|tes=32  tientpD<l(t)  TTL=128 
íi‘3spiies:ta  desde  192-168.0-1=  b*;tes=32  tiempo  =±!ns  TTL-128 
Respuesta  desde  192_i6B_0_l=  b5ites-32  tiefTipo<liíi  TTL-128 

í'ttad ícticas  de  ping  pai'-a  192.168-0-1  = 

Paquetes:  enviados  =  4,  recibidos  =  4^  perdidos  -  0 
<0>i  perdidos  >, 

I  iempos  aproximados  de  ida  y  vuelta  en  milisegundos : 
Hinimo  =  0íns,  náxiino  -  Ims,  Media  -  0ns 

C:\>app  -a 

Interfaz:  192. 168. 0_2  - 0x2 

Dirección  IP  Dirección  física  Tipo 

192-168.0.1  00-03“ff-a7-88“S9  dinámico 

C:\>arp  -s  192.168.0.1  00-01-02-03-04-05 

f;;\>ping  192.168.0.1 

Haciendo  ping  a  192-168-0.1  con  32  bytes  de  datos: 

iicpipo  de  espera  agotado  para  esta  solicitud- 

Cstadís ticas  de  ping  para  192.168.0.1: 

Paquetes:  enviados  =1,  recibidos  -  perdidos  =  1 
I  C100:}^  perdidos >, 

Control-G 

U:\>arp  —a 

interfaz:  192-168-0.2  — 0x2 

!  Dirección  IP  Dirección  física  Tipo 

;  Í92-168.0-Í  00-01 -02  "^03 -84-05  estático 


bJ 


C  =  N>. 


Ftg.4X.- Tabla  ARP. 
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La  anterior  imagen  muestra  una  secuencia  de  introducción  falseada  de  una  dirección  física, 
de  tal  fonna  que  la  construcción  de  las  tramas  ICMP  {Jnternet  Control  Message  Protocol) 
hacia  la  dirección  ÍP  1 92.168.0.1,  se  realiza  con  una  dirección  MAC  errónea. 

La  información  enviada  (trama  ICMP)  no  llegará  a  ningún  destino  o  a  todos  dependiendo 
nuevamente  de  la  tcenología  del  Switch  empleado.  Si  el  destino  no  es  conocido  por  el  switch 
(la  dirección  MAC  00-01-02-03-04-05  en  el  caso  anterior)  puesto  que  no  se  encuentra  en  su 
tabla  CAM,  el  dispositivo  podría  bien  rechazar  el  paquete  o  bien  reenviarlo  por  todos  los 
puertos.  La  importancia  de  mantener  una  información  correcta  es  ostensible  en  este  punto.  Si 
se  aprende  una  información  errónea  el  sistema  no  va  a  tomar  la  decisión  de  intentar  evaluar 
si  dicha  información  está  mal,  simplemente  se  entenderá  que  el  equipo  no  se  encuentra 
disponible.  Para  evitar  el  problema  de  que  la  infomiación  mantenida  sea  errónea  durante 
un  tiempo  considerable,  por  ejemplo  en  situaciones  de  red  con  implementación  de  DHCP 
y  direcciones  ¡P  que  pueden  cambiar  con  respecto  a  la  dirección  física,  la  obtenida  de 
forma  automática  es  considerada  dinámica  y  limitada  en  el  tiempo.  Basado  en  estadísticas 
de  uso,  dicha  información  será  eliminada  de  la  tabla  ARP  local  transcurrido  un  tiempo. 
Sin  embargo  la  infonnación  introducida  manualmente  se  considera  estática  y  mantenida 
hasta  que  bien  sea  eliminada  o  sobrescrita  manualmente  o  se  reinicie  el  servicio  asociado. 
El  siguiente  ejemplo  muestra  la  infonnación  estática  e  información  manual  dentro  de  una 
tabla  ARP. 


Fig.  4.9.-  Entrada  estática  y  dinámica  en  una  tabla  ARP. 


Basado  en  la  infonnación  anterior,  el  ataque  ARP  Spoofmg^  se  articula  de  la  siguiente 
forma: 


-  Un  atacante  denominado  sistema  II  con  dirección  IP  H  y  Mac  H,  quiere  ponerse 
en  medio  de  la  comunicación  entre  el  sistema  A  con  dirección  IP  A  y  Mac  A,  y  el 
sistema  B  con  dirección  IP  B  y  Mac  B. 
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-  Para  ello  manda  tramas  ARP  Reply  a  cada  uno  de  ellos.  Al  Sistema  A  le  indica 
que  IP  B  se  corresponde  con  MAC  H.  Al  sistema  B  ie  indica  que  IP  A  se  corresponde 
con  MAC  H. 

-  Cuando  ambos  sistemas  reciban  la  información  y  lo  almacenen  en  sus  tablas  ARP, 
se  encontrarán  ya  engañados.  El  sistema  A  comunicará  con  la  IP  B  pero  enviándoselo 
realmente  a  M  AC  H. 

-  Con  la  contribución  del  Switch  la  información  que  parte  del  sistema  A  llegará  al 
sistema  con  MAC  H,  es  decir  el  sistema  H*  B  nunca  recibirá  esa  infonnación  porque 
el  switch  no  va  a  enviarlo  a  una  MAC  no  declarada. 

-  El  sistema  H  debe  ser  lo  sufícientemente  rápido  para  recoger  la  comunicación 
y  modificar  las  direcciones  MAC  de  origen  y  destino  para  que  la  petición  llegue 
finalmente  al  sistema  B,  MAC  de  origen  H,  MAC  de  destino  B. 

-  Esta  trama  nuevamente  con  la  participación  del  comnutador,  llegará  solamente  a 
B  y  por  lo  tanto  la  trama  llega  al  destino. 

-  La  respuesta  que  el  sistema  B  pudiera  enviar  al  equipo  B  cursará  el  camino  y 
proceso  inverso. 


Este  ataque  es  conocido  también  popularmente  con  el  nombre  del  hombre  en  medio  (MITM). 
Cualifica  perfectamente  el  objetivo  y  consecuencia  de  la  acción  maliciosa.  La  siguiente 
imagen  muestra  la  secuencia  de  envenenamiento  ARP,  donde  puede  apreciarse  que  para 
dos  direcciones  IP  diferentes  existen  dos  direcciones  ARP Rep/y  distintas,  asignadas  con  la 
misma  dirección  física. 
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Para  que  el  ataque  sea  efectivo  se  necesitan  una  serie  de  circunstancias: 

-  Que  el  atacante  tenga  visibilidad  en  el  segmento  físico  con  las  víctimas,  o  al 
menos  una  de  ellas  y  el  Router  que  encaminará  sus  tramas  fuera  del  segmento  lógico 
que  le  corresponda. 

-  Que  el  engaño  sea  mantenido  durante  el  tiempo  que  sea  necesario  para  realizar  el 
ataque.  Para  evitar  que  las  víctimas  descubran  la  información  auténtica,  el  sistema 
atacante  debe  reenviar  cada  cierto  tiempo  tramas  ARP  Reply  falsas.  Esto  hará  que 
dicha  información  se  encuentre  siempre  en  las  tablas  ARP  locales  de  las  victimas. 
Puesto  que  las  víctimas  poseerán  ia  información  necesaria  para  la  comunicación,  no 
tratarán  de  obtenerla  por  sus  propios  medios. 

-  Que  el  atacante  ofrezca  una  buena  respuesta  para  que  no  haya  interrupción  de  la 
comunicación. 


La  siguiente  imagen  muestra  una  traza  de  comunicación  vista  desde  el  punto  de  vista  del 
atacante,  donde  se  puede  apreciar  el  proceso  de  modificación  de  los  datos  a  nivel  de  capa  2 
para  que  el  engaño  producido  sea  efectivo.  La  comunicación  corresponde  con  peticiones  y 
respuestas  ICMP  hechas  con  la  aplicación  píng 
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Se  puede  ver  coma  cada  petición  y  respuesta  de  Echo  ICMP^  se  encuentra  duplicada.  Esto 
es  debido  a  que  visto  desde  el  punto  de  vista  del  atacante  la  petición  viene  del  sistema 
A  y  sale  hacia  el  sistema  B.  Esto  evidentemente  genera  más  tráfico  de  red  que  el  que  se 
produciría  en  una  comunicación  que  no  se  encontrara  envenenada.  También  hay  que  tener 
en  cuenta  que  la  tecnología  actual  admite  este  aumento  de!  número  de  tramas,  no  siendo  un 
problema  significativo. 


También  en  ello  la  respuesta  del  atacante  es  importante  para  no  interrumpir  la  comunicación. 
Pero  nuevamente  con  la  capacidad  de  procesamiento  y  la  respuesta  que  ofrecen  los 
adaptadores  de  red,  hacen  que  las  víctimas  no  aprecien  la  mínima  latencia  que  se  produce 
por  la  realización  del  ataque.  Actualmente  existen  dos  aplicaciones  que  pueden  considerarse 
como  de  las  más  significativas  en  cuanto  al  ataque  de  ÁRP  Spoqfing:  Cain  y  Abel  para 
sistemas  Windows  y  Ettercap  para  sistemas  Windows  y  Linux.  Aunque  no  son  las  únicas 
existentes,  quizás  su  potencia  y  comodidad  de  uso  las  han  hecho  las  más  utilizadas.  En  este 
capítulo  se  hará  un  inciso  mayor  en  ia  primera  de  las  aplicaciones,  dejándose  la  segunda 
para  otros  ataques  que  serán  referidos  en  otros  capítulos. 
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Fig,  4, 12.-  Hscanco  de  direcciones  MAC. 


Caín  y  Abe}  como  ya  se  ha  mencionado  es  una  herramienta  con  un  largo  recorrido.  Aunque 
tiene  múltiples  propósitos,  el  de  MITM  es  uno  de  los  más  significativos,  generando  en  base 
a  este  un  número  importante  de  ataques  basados  en  otras  técnicas  de  Spoofmg  y  Híjacking. 
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El  proceso  que  siguen  todas  las  herramientas  de  hombre  en  medio  es  similar: 

-  Delectar  los  sistemas  existentes» 

-  Decidir  entre  qué  sistemas  hay  que  interponerse. 

-  Lanzar  el  ataque. 


La  detección  de  sistemas  existentes  se  realiza  en  base  a  peticiones  ARP  o  bien  realizando 
diferentes  tipos  de  test  de  tipo  ICMP.  El  problema  de  este  tipo  de  análisis  se  basa 
en  que  generan  un  ruido  en  la  red  fácilmente  trazable»  Esto  es  debido  a  que  utilizan 
convencionalmente  una  secuenciación  de  ARP  Request  con  objeto  de  determinar  los 
sistemas  existentes.  Esta  secuenciación  hace  predecible  que  puede  estar  pasando,  por  lo 
que  los  sistemas  de  detección  de  intrusiones  hacen  que  sea  fácil  de  detectar  un  escaneo  de 
este  tipo. 

Quizá  el  mejor  sistema  para  evitar  la  detección  pase  por  introducir  un  factor  aleatorio  y  nada 
mejor  para  ello  que  el  humano.  Aunque  implica  un  mayor  tiempo  de  proceso,  garantiza  que 
esta  fase  del  proceso  no  sea  detectada.  Esto  implica  realizar  conexiones  a  direcciones  IP 
de  la  organización,  por  ejemplo  mediante  peticiones  ping  (no  incurrir  en  el  mismo  error 
de  secuenciación).  La  información  de  direcciones  IP  y  MAC  habrán  quedado  almacenadas 
en  la  tabla  correspondiente.  Solo  hay  que  extraerla  y  alimentar  con  ella  el  fichero  de 
configuración  Hostsdst  de  Caín  y  Abel^  existente  en  la  ruta  de  instalación  de  la  aplicación. 


Fig.  4. 1 3.-  Fichero  de  con  figuración  Hosts  Jsi. 
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Aunque  el  ataque  base  de  ARP  Poisoning  está  basado  en  la  del  envío  de  tramas  ARP 
Reply  para  mantener  el  engaño,  en  algunos  escenarios  puede  llegar  a  fallar.  Determinados 
entornos  (configuraciones  de  electrónica  de  red  principalmente),  pueden  descartar  tramas 
de  ARP  Reply  si  en  la  comunicación  no  ha  existido  una  petición  de  tipo  ARP  Request 
previa.  Para  evitar  este  problema,  las  herramientas  de  MITM  pueden  enviar  peticiones  de 
tipo  ARP  Request  hacia  las  víctimas  colando  en  medio  la  respuesta  ARP  falseada.  Aunque 
evidentemente  esto  va  a  generar  más  tráfico,  no  es  tan  crítico  como  para  que  suponga  un 
colapso  de  red. 


Fig,  4,14,-  Configuración  de  ARP  Reqiíesí  para  el  enveneníiniiento. 


Este  ataque  se  encuentra  limitado  a  la  red  de  área  local  en  el  segmento  físico.  No  podrá 
por  lo  tanto  envenenarse  una  conexión  entre  dos  sistemas  que  se  encuentran  en  una  VEAN 
diferente  al  atacante.  Si  quiere  interceptarse  el  tráfico  que  un  sistema  envía  a  Internet  o  a 
otros  servidores  que  se  encuentran  fuera  del  segmento  lógico  de  la  víctima,  podrá  realizarlo 
envenenando  a  esta  con  el  Router  de  la  red.  De  esta  forma  todo  el  tráfico  que  la  víctima 
envíe  fuera  de  la  red  (hacia  Internet  u  otros  segmentos  físicos  o  lógicos),  pasará  y  podrá  ser 
manipulado  por  el  atacante. 

Otro  ataque  factible  para  robar  información  aunque  implica  un  mayor  riesgo  de  detección  y 
de  caída  de  los  sistemas  de  red,  consiste  en  el  robo  de  puerto.  Este  ataque  realizable  desde 
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la  aplicación  Ettercap  representa  una  alternativa  cuando  el  ataque  de  hombre  en  medio 
con  ARP  Púisonmg  no  es  factible.  El  robo  de  puerto  consiste  básicamente  en  confundir  ai 
Swítch  con  la  información  de  su  tabla  CAM.  La  base  no  es  desbordar  la  tabla,  como  en  el 
caso  del  ataque  con  la  aplicación  macojy  sino  la  de  ganar  la  condición  por  persistencia,  de 
que  la  dirección  MAC  de  la  víctima  se  encuentra  conectado  al  mismo  puerto  que  la  máquina 
atacante.  Las  tramas  ARP  que  envía  el  atacante  con  objeto  de  ganar  esa  competencia  se 
mantendrá  hasta  que  la  información  dirigida  a  la  víctima  llegue  al  atacante.  Cuando  así 
sea,  se  enviará  una  petición  ARP  legítima  a  la  victima  para  que  en  la  respuesta,  el  Sv^dtch 
aprenda  bien  en  que  puerto  se  encuentra  la  dirección  MAC  amenazada.  De  esta  forma  se 
permite  la  comunicación  correcta  con  la  máquina  víctima  y  a  iniciar  nuevamente  el  ataque. 


Fig,  4, 154-  Ataque  de  robo  de  puerto. 


Este  ataque  no  permite  la  alteración  de  los  paquetes,  si  no  solamente  la  captura  de  la 
información,  no  es  un  ataque  de  MITM.  También  como  ha  quedado  reflejado  ralentizará 
la  comunicación  y  hay  un  riesgo  elevado  de  interrumpir  las  sesiones  o  incluso  acabar 
denegando  conexiones  legítimas. 


4.3.-  Ataque  en  la  capa  de  red 

Aunque  el  ataque  de  ARP  Poisoning  es  potencialmente  el  más  funcional  para  la  realización 
de  la  técnica  de  hombre  el  medio,  no  es  el  único  existente.  Aun  siendo  menos  funcional, 
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existe  también  la  posibilidad  de  hacer  uso  de  la  técnica  de  ICMF  Redirecí.  Este  ataque 
presenta  un  problema  fundamenta!  y  es  que  no  es  factible  realizarlo  en  una  red  con  Switch, 
se  encuentra  limitado  a  una  red  con  concentradores.  Pero  sin  en  una  red  con  concentradores 
la  información  ya  llega  al  atacante  ¿para  qué  vale?  Pues  en  este  caso  para  manipular  el 
tráfico  que  envía  la  %dctima. 

El  ataque  de  ¡CMP  Redirecí  se  basa  en  el  envío  a  un  equipo  de  la  red  de  un  mensaje  de 
redireccíón  ICMP,  haciendo  creer  que  es  la  mejor  mta  hacia  Internet.  Todas  las  conexiones 
serán  enviadas  al  atacante,  el  cual  las  enviará  al  Gateway.  El  ataque  es  de  tipo  MITMHalf- 
Dí/pfex,  es  decir  solo  hacia  un  sentido:  víctima  haciaelroutenElrouter  enviará  las  respuestas 
directamente  hacia  el  cliente.  Es  importante  tener  en  cuenta  que  no  debería  modificarse  el 
tamaño  del  paquete,  puesto  que  entonces  se  produciría  un  fallo  en  la  secuencia  TCP  al  no 
poder  ser  actualizado  en  ambos  sentidos*  Los  paquetes  podrán  ser  alterados  pero  deberá 
mantenerse  el  tamaño. 


Fig,  4. 16.“  Alaque  de  ICMF  Redirect, 

Para  que  este  ataque  sea  factible  hay  que  facilitar  como  datos  la  dirección  MAC  y  la  IP  del 
router  real.  Este  ataque  como  se  ha  dicho  implica  que  no  puede  ser  utilizado  en  una  red  con 
dispositivos  de  conmutación. 

En  la  capa  de  red  se  dan  también  otros  tipos  de  ataques  donde  los  más  significativos 
corresponden  con  las  técnicas  de  Spoofmg  de  protocolos  de  enruLamiento,  La  capacidad 
para  alterar  las  rutas  de  encaminamiento  permitiría  a  un  atacante  reconducir  el  tráfico  a  su 
antojo  a  la  vez  que  podría  analizar  el  tráfico  circulante.  La  idea  fundamental  es  ganar  la 
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confianza  y  declarar  ser  la  mejor  opción  o  bien  inyectar  nuevas  rutas  en  los  dispositivos  de 
enrutamiento.  La  mayor  parle  de  protocolos  de  enrutamiento  dinámieos  determinan  que  la 
mejor  forma  de  llegar  a  un  punto  viene  detenninada  por  un  proceso  de  prelación.  El  mismo 
se  consigue  estableciendo  la  menor  ruta  factible  como  la  más  óptima  en  una  métrica  de 
rutas.  Si  se  alteran  las  rutas  o  se  introducen  nuevas,  podría  suponer  una  reconfíguración  del 
escenario  muy  significativo. 

Aunque  no  es  muy  habitual  que  los  protocolos  de  enrutamiento  dinámicos  sean  utilizados 
en  las  redes  internas  de  una  organización,  a  veces  por  la  complejidad  de  las  mismas,  se 
hace  necesario  emplearlos.  En  otras  ocasiones  se  encuentran  activos  en  los  dispositivos 
de  enrutamiento  pero  no  configurados.  Las  condiciones  de  enrutamiento  entre  VLAN, 
también  necesitan  de  la  configuración  de  rutas  y  a  veces  son  mantenidos  automáticamente 
por  los  dispositivos  de  Capa  2/3,  sin  la  intervención  del  administrador  de  red.  Estas 
situaciones  podrían  ser  aprovechadas  por  un  atacante  para  mediatizar  el  tráfico  que  circula 
en  la  organización. 

Actualmente  la  aplicación  Lokí  (disponible  a  través  de  la  web  de  sus  desarrolladores  www. 
ernw.de)^  presentada  en  la  Black  Hack  del  2010,  constituye  una  de  las  herramientas  más 
potentes  para  conseguir  estos  objetivos. 


4.4.-  Ataque  en  la  capa  de  aplicación 

La  últimade  las  capas  constituye  en  esencia  la  máscríticaparael  usuario  de  una  organización. 
Aquí  se  implementan  los  protocolos  de  más  alto  nivel,  y  de  una  u  otra  forma  los  que  están 
más  relacionados  con  las  personas.  Contraseñas,  tbrinularios  o  documentos,  son  algunos  de 
los  ejemplos  de  información  sensible  que  se  manejan  en  dicha  capa  de  aplicación. 

Al  final  los  objetivos  de  los  ataques  realizados  en  las  capas  anteriores  lo  constituye  la 
información  que  se  maneja  en  esta  ultima.  El  ataque  de  ARP  Poisoning  no  tiene  sentido 
si  posteriormente  no  se  van  a  recoger  los  datos  que  envían  los  usuarios.  La  interpretación 
de  la  información  la  puede  dar  bien  la  misma  herramienta  de  MITM  o  bien  podrá  ser 
reconstruida  por  otra  adicional  que  tenga  la  capacidad  de  leer  y  entender  la  información  que 
se  recibe  una  vez  que  el  ataque  ha  sido  eficazmente  realizado. 

No  obstante  hay  que  entender  que  en  ocasiones  la  adquisición  de  datos  por  la  aplicación 
no  resulta  todo  lo  eficaz  que  pudiera  ser.  Esto  se  encuentra  motivado  fundamentalmente  en 
que  las  herramientas  han  sido  configuradas  con  unos  parámetros  concretos.  Por  ejemplo 
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la  mayor  parte  de  aplicaciones  MITM  tienen  la  capacidad  de  mostrar  como  resultado  de 
conexiones  tipo  HTTP,  la  contraseña  que  hubiera  sido  interceptada  de  una  potencial  víctima 
en  el  acceso  a  un  formulario  de  autenticación.  Sin  embargo  hay  que  tener  en  cuenta  varios 
aspectos.  El  primero  consiste  en  que  no  todas  las  peticiones  HTTP  tienen  que  ser  llevadas 
a  cabo  por  el  puerto  80.  Por  ejemplo  existen  sitios  web  que  no  escuchan  por  el  puerto  por 
defecto,  u  otra  más  habitual  como  el  de  la  existencia  de  un  servidor  proxy  por  el  cual  los 
usuarios  saldrán  hacia  Internet.  Si  se  intercepta  a  una  víctima  con  el  router  o  el  proxy  si  está 
en  su  mismo  segmento,  es  factible  que  la  aplicación  no  muestre  información  puesto  que  no 
estará  preparada  para  identificar  tráfico  HTTP  por  el  puerto  del  proxy. 


En  estas  circunstancias  el  ataque  parece  no  ser  efectivo,  pero  el  problema  consiste  en  que  no 
se  han  evaluado  todos  los  factores,  ¿Qué  pasaría  si  una  conexión  de  tipo  FTP  no  fuera  por 
el  puerto  2 1?  Seguramente  la  aplicación  atacante  que  no  se  encuentra  configurada  para  ello, 
no  advertiría  este  hecho.  La  siguiente  imagen  muestra  la  configuración  predeterminada  de 
Caín  y  Abel  pñm  el  establecimiento  de  uso  de  protocolos  y  sus  puertos  correspondientes.  Si 
por  ejemplo  se  determina  que  la  organización  presenta  un  proxy  por  el  puerto  8888,  debería 
realizarse  la  rectificación  correspondiente  para  especificar  que  dicho  puerto  será  necesario 
examinarlo  con  las  mismas  condiciones  que  el  puerto  80.  Si  una  organización  presenta  una 
intranet  en  IITTPS  por  el  puerto  4443  deberá  establecerse  lo  propio  en  las  opciones  de 
configuración. 


Fig,  4, 1 7,-  C'onfígiiración  de  puertos  y  protocolos. 
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Otra  circunstancia  simiJar  sucede  con  los  formularios  de  las  aplicaciones  Web.  Coirio 
se  comentaba,  un  objetivo  fundamental  del  ataque  consiste  en  el  robo  de  credenciales, 
y  las  conexiones  web  basadas  en  formularios  pueden  ser  de  las  más  interesantes  para 
un  atacante.  Sin  embargo  la  aplicación  como  en  el  caso  anterior  no  conoce  todas  las 
casuísticas  de  formularios.  Será  necesario  hacer  entender  a  !a  aplicación  qué  campos 
pueden  corresponder  con  un  usuario  y  cuales  con  contraseñas.  De  esta  forma  si  intercepta 
una  entrada  de  autenticación  basada  en  fonnulario  donde  se  hayan  introducido  datos  en 
campos  de  usuarios  y  contraseñas  identifi cables,  la  herramienta  los  mostrará  por  pantalla. 
La  siguiente  imagen,  muestra  la  configuración  para  la  identificación  de  los  campos  usuario 
y  contraseña  que  analiza  Caín  y  Abel  cuando  analiza  tráfico  HTTP  y  HTTPS. 


Fíg,  4.18.-  Introducción  de  datos  para  análisis  de  campos. 


El  elemento  base  de  captura  de  información,  se  corresponde  con  las  credenciales. 
Dependiendo  de  la  aplicación  su  funcionalidad  podrá  ser  mayor  o  menor,  o  bien  orientada 
hacia  un  tipo  de  escenario  concreto.  Las  credenciales  podrán  ser  interceptadas  en  claro  o 
bien  haber  utilizado  alguna  función  algorítmica  más  o  menos  compleja  para  dificultar  su 
obtención.  Nuevamente  las  aplicaciones  contarán  con  mejores  funcionalidades  o  no  para 
su  interpretación,  pudiendo  atacar  aquellas  que  se  encuentre  debidamente  protegidas.  La 
siguiente  imagen  muestra  un  ejemplo  de  aquellos  tipos  de  credenciales  que  pueden  ser 
capturadas  y  analizadas  directamente  por  Caín  y  Abel  a  través  de  los  ataques  de  MíTM. 
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Fig.  4. 1 9  -  Credenciales  obtenidos  por  Caín  y  Abel. 


Determinadas  claves  que  no  se  encuentren  en  texto  plano,  puesto  que  se  ha  utilizado  una 
función  para  que  no  sean  legibles,  podrán  ser  enviadas  al  módulo  Cracker  con  objeto  de 
que  puedan  ser  atacadas. 
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Fig.  4.20,-  Módulo  Cracker. 
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La  siguiente  imagen  muestra  el  resultado  de  un  ataque  satisfactorio  de  MITM  donde  al 
usuario  se  le  ha  interceptado  un  proceso  de  autenticación  de  tipo  Webmail  en  HTTP. 
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Fig,  4.2  L-  Obtención  de  clave  en  un  fomiulario  HTTP. 


En  esta  circunstancia  la  cuestión  era  simple  puesto  que  la  información  viajaba  en  un  modo 
no  seguro  (HTTP)  y  no  existía  ningún  mecanismo  que  cifrara  la  contraseña,  ¿Qué  hubiera 
pasado  en  caso  de  una  petición  HTTPS?  Bueno,  pues  la  respuesta  vendrá  en  el  siguiente 
capítulo,  donde  se  tratarán  diversos  ejemplos  de  comunicaciones  seguras.  Hay  numerosos 
protocolos  que  envían  la  infomiación  de  autenticación  en  texto  plano  y  esto  supone  un 
riesgo  significativo  para  la  organización*  Aunque  son  utilizadas  por  administradores  en 
el  acceso  a  los  dispositivos  como  Telnet  y  otras  por  todos  los  usuarios  como  FTP,  POP3, 
IMAP4,  etc.,  todos  ellos  tienen  sus  equivalentes  seguros,  que  ofrecen  mejores  garandas 
frente  a  un  potencial  ataque,  pero  nuevamente  bien  por  desconocimiento  o  por  laxitud  no 
son  utilizados. 
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No  meoos  importante  son  las  claves  correspondientes  a  la  autenticación  en  infraestructuras 
de  dominio,  tales  como  los  acceso  SMB  {Server  Message  Black)  a  recursos  en  sistemas 
Microsoft  mediante  diferentes  tipos  de  autenticación  tradicionales  (LM,  NTLM  oNTLMy2), 
autenticaciones  Kerberos  o  las  de  tipo  LDAP  {IJghtweight  Directory  Access  Protoco!), 
La  obtención  de  este  tipo  de  credenciales  supone  un  factor  decisivo  en  determinadas 
circunstancias,  puesto  que  supone  para  un  atacante  el  acceso  a  múltiples  servicios: 
intranets,  servidores  de  ficheros,  correo  electrónico,  aplicaciones  internas,  bases  de  datos, 
etc.  Los  sistemas  de  autenticación  anterionnente  citados,  a  excepción  del  de  LDAP,  utilizan 
funciones  para  hacer  no  legible  la  contraseña.  Los  algoritmos  empleados  en  los  diferentes 
protocolos  de  autenticación,  varían  en  diferentes  factores  donde  la  robustez  del  mismo 
es  quizás  el  más  significativo.  Los  más  antiguos  como  en  el  caso  de  LM  (Lan  Manager) 
son  sistemas  que  a  día  de  hoy  deberían  ser  desestimados  por  las  organizaciones,  y  otros 
como  NTLMv2  {New  Technology  Lan  Manager)  presenta  mucha  más  dificultad  para  que 
el  atacante  obtenga  !a  clave  en  texto  plano. 

No  es  objetivo  de  este  libro  tratar  estos  mecanismos  de  autenticación,  pero  una  organización 
sí  deberá  evaluar  una  serie  de  aspectos  fiindamentales: 

-  Algoritmos  y  sistemas  de  autenticación  más  modernos  dificultan  por  regla  general 
la  obtención  final  de  la  credencial  en  texto  plano. 

-  En  ocasiones  el  empleo  de  sistemas  operativos  modernos  no  implica 
automáticamente  que  se  vaya  a  emplear  algoritmos  reciente*  Hay  que  contar  que  en 
ocasiones  los  procesos  de  compatibilidad  reducen  la  seguridad  de  la  comunicación. 
También  la  seguridad  además  depende  de  dos  sistemas,  no  solo  de  uno  de  ellos, 
puesto  que  debe  existir  un  proceso  de  negociación.  En  este  proceso,  la  seguridad  se 
puede  ver  mermada  en  una  negociación  a  la  baja* 

-  Los  sistemas  de  autenticación  difieren  entre  los  que  utilizan  semilla  o  no.  Este 
elemento  hace  que  dada  una  contraseña,  el  hash  derivado  de  aplicar  la  función 
algorítmica  lo  haga  diferente  en  base  a  diferentes  condiciones*  Por  ejemplo  los 
algoritmos  LM  o  NTLM  en  su  almacenamiento  de  credenciales  locales,  no  utilizan 
ningún  mecanismo  basado  en  semilla.  Esto  implica  que  la  palabra  “casa”  originará 
siempre  el  mismo  hash  para  el  mismo  algoritmo,  independientemente  del  lugar  y 
tiempo  donde  se  aplica.  Por  contra  el  algoritmo  Kerberos  utiliza,  además  de  una 
doble  función  de  algoritmo,  una  marca  tiempo  con  el  que  generar  el  hash  final  del 
proceso  de  pre-autenticación  Kerberos.  Este  último  constituye  uno  de  los  mejores 
mecanismos  de  autenticación  basado  en  contraseñas-  Las  contraseñas  utilizadas  en 
protocolos  con  algoritmos  sin  semilla  presentan  mayor  factor  de  ataque  derivado  del 
uso  de  hashes  previamente  calculado* 
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-  En  procesos  donde  la  autenticación  sea  constante,  existe  más  posibilidad  de 
que  un  potencial  atacante  pueda  obtener  las  credenciales.  Existen  mecanismos  de 
autenticación  como  Kerheros  que  utilizan  para  el  acceso  a  recursos  y  servicios  un 
sistema  basado  en  Tickets  que  no  implica  el  envió  constante  de  las  credenciales. 
Frente  a  este,  otros  accesos  basados  en  SMB  requieren  el  envío  de  las  credenciales 
cada  vez  que  se  accede  a  un  recurso  como  una  impresora  o  un  servidor  de  ficheros. 


No  obstante  hay  que  tener  también  en  cuenta  que  la  complejidad  de  la  clave,  longitud 
y  factores  como  que  aparezcan  o  no  en  diccionario,  implica  que  un  protocolo  por  muy 
robusto  que  pueda  llegar  a  ser  no  proporcione  la  seguridad  debida.  Las  siguientes  imágenes 
muestran  el  resultado  del  ataque  que  se  realiza  tras  el  proceso  de  inicio  de  sesión  de  un 
usuario  de  dominio  en  un  Directorio  Activo. 
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Fig.  4.23.-  Obtención  del  proceso  de  pre-auicniicación  KerhercKs. 


Durante  el  proceso  de  inicio  de  sesión,  cuando  el  usuario  introduce  sus  credenciales 
para  validarlas  en  el  dominio,  se  produce  el  proceso  de  generación  de  la  trama  de  pre- 
autenticación  Kerheros  que  se  muestra  en  la  captura  de  la  imagen  previa.  El  hash  derivado 
de  la  clave  se  basa  en  la  ímplementación  de  la  función  HMAC  (Hash-based  Message 
Authentícaííon  Cade)  y  el  sistema  de  cifrado  de  flujo  Síream  Cipher  RC4,  tal  y  como  se 
describe  en  la  RFC  4757.  Utiliza  como  semilla  la  marca  tiempo  hora,  por  lo  que  el  factor 
de  ataque  contra  el  hash  es  muy  bajo  con  respecto  a  otros  algoritmos. 


No  obstante  tal  y  como  se  muestra  en  la  siguiente  imagen,  una  contraseña  muy  débil,  como 
la  palabra  '’admin’V  indica  que  nada  es  totalmente  seguro. 
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Fig.  424  -  Contrascfía  obtenida  en  texto  plano. 

Una  condición  muy  importante  en  lo  referente  a  la  seguridad  es  que  una  organización  es 
tan  vulnerable,  eomo  el  elemento  más  débil  de  todo  su  sistema.  Si  las  contraseñas  utilizadas 
para  autenticar  en  el  dominio  son  muy  robustas,  será  muy  complejo  poder  obtenerlas  en 
texto  plano.  Sin  embargo  es  posible  que  sea  más  fácil  obtenerlas  por  otro  vía,  por  ejemplo 
LOAR  Hay  que  tener  presente  que  el  Directorio  Activo  es  entre  otras  cosas  una  base  de 
datos  LDAP  que  admite  autenticación  basado  en  este  protocolo.  Éste  no  utiliza  ningún 
mecanismo  de  forma  nativa  para  e!  cifrado  de  la  contraseña,  viaja  en  texto  plano  por  la  red 
y  salvo  que  se  utilice  la  variante  LDAP-S  podría  ser  factible  obtener  la  credencial  de  forma 
más  simple  que  atacando  la  pre-autenticación  Ker teros.  Muchas  aplicaciones  utilizan 
conexiones  LDAP  contra  im  sistema  de  directorio  en  vez  de  la  autenticación  integrada 
nativa  que  puede  proporcionar  por  ejemplo  ios  dominios  MícrosojL  El  ataque  MITM  podria 
suministrar  al  atacante  claves  que  de  otra  forma  sería  prácticamente  imposible  obtener 


Fig,  4.25  -  Capí  Lira  sesión  autenticación  LDAP. 
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La  anterior  imagen  muestra  el  resultado  de  un  proceso  de  captura  de  sesión  de  autenticación 
LDAP,  donde  el  usuario  Administrador  con  la  contraseña  “123abc.”,  ha  sido  atacado 
mediante  un  proceso  de  MITM.  Es  importante  hacer  constar  que  no  solo  las  credenciales 
van  en  texto  plano  sino  todo  el  proceso  de  comunicación,  como  la  obtención  de  información 
del  árbol  LDAP.  La  siguiente  imagen  muestra  el  resultado  de  la  interceptación  del  tráfico 
mostrado  con  IL/rer/iarA:  aprovechando  el  ataque  de  MfTM  realÍ7ado. 


Fig.  4.26.-  Tramas  de  sesión  LDAP  ánlerceplada. 


Aunque  la  obtención  de  credenciales  consiste  en  el  elemento  fundamental  de  un  atacante, 
a  veces  hay  otros  objetivos  no  menos  importantes.  Por  ejemplo  la  interceptación  de  un 
fichero  que  una  víctima  está  copiando  desde  un  servidor  de  ficheros.  El  proceso  de  copia  de 
un  fichero  por  la  red  sigue  un  patrón  definido  que  puede  ser  interpretado  y  haciendo  uso  de 
las  herramientas  adecuadas,  el  atacante  podrá  reconstruirlo  igual  que  el  sistema  del  usuario 
lo  realiza  automáticamente. 


El  siguiente  ejemplo  muestra  el  resultado  de  reconstrucción  de  un  fichero  interceptado 
haciendo  uso  de  la  técnica  de  MITM.  Para  la  reconstrucción  de  los  ficheros  se  ha  empleado 
la  herramienta  de  tipo  forense  NetworkMuier.  Esta  es  capaz  de  interpretar  el  tráfico 
capturado  reagrupando  las  tramas  por  conversaciones  y  reconstruyendo  determinados 
elementos  significativos.  Esta  herramienta  además  de  la  reconstrucción  de  ficheros,  muestra 
resultados  muy  interesantes  de  los  sistemas  atacados. 
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Fig,  4.27.-  írifonTi ación  proporcionada  por  NetworkMwer  del  ser\  idor 


En  esta  circunstancia  un  cliente  ha  accedido  al  ser\ádor  a  través  de  la  red  para  recuperar  un 
fichero  existente  en  su  carpeta  personal.  Con  el  tráfico  reconducido  a  través  de  la  máquina 
del  atacante,  la  aplicación  NetworkMiner  ha  reconstruido  dicho  fichero,  encontrándose 
disponible  para  el  atacante. 


Fig.  4.2S.-  Fichero  reconstruido  NeiworkMiner. 


igual  que  se  ha  producido  el  acceso  a  un  servidor  de  fichero,  podría  haberse  realizado 
igualmente  en  la  interceptación  del  envío  del  fichero  al  servidor  de  impresión  o  cualquier 
otro  contexto  similar.  A  veces  para  el  atacante  puede  ser  más  fácil  recuperar  información 
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crítica  de  esta  forma  que  de  otra.  ¿Qué  podría  suponer  interceptar  un  fichero  con  todas  las 
claves  utilizadas  para  el  acceso  a  los  servidores  de  la  organización? 


No  podría  finalizarse  este  punto  sin  mostrar  un  ejemplo  de  ataque  puro  de  hijacking,  donde 
aunando  las  capacidades  de  reconducción  de  tráfico,  este  es  alterado  para  que  el  atacante 
pueda  sacar  partido  de  la  confusión  generada.  Un  ejemplo  evidente  lo  proporciona  el  ataque 
de  DNS  Spoofing.  A  través  de  éste,  un  atacante  que  intercepte  una  petición  de  resolución 
DNS  podría  modificarla  cuando  fuera  devuelta  a  la  victima  tras  la  respuesta  dada  por  el 
servidor  correspondiente. 

De  esta  fonna  la  víctima  podría  ser  reconducida  a  un  servidor  web  que  aparentara  ser,  al 
que  desea  ir.  Crear  confusión,  robar  sesiones  o  credenciales,  constituye  algunos  de  los 
objetivos  últimos  del  empleo  de  esta  técnica.  En  el  ejemplo  siguiente  una  víctima  solicita 
resolver  la  dirección  IP  del  servidor  de  intranet  de  la  organización.  El  atacante  haciendo 
uso  del  envenenamiento  ARP  habrá  interceptado  y  alterado  la  información  devuelta  por  el 
servidor  DNS. 


File  Ví«(f  Configure  Toots  Hdp  j 

|i!ljl|i&¡®  lif  S 

]  ^  un  lü  g  a  O  ^  n  1 0  f 

JL 

1^  DtcodsKS  Met¥ivr(c  |ll^  Srtiffíf  |s^  Cracker  |Cl  Trirceroute  |ffi|  CC.DU  Wireíess  1®?  Query  | 

©  APR 

M  APR'Cert 
^  APR-ObÉS 

m  APR  ssH-i  m 
APR-mrpsíO) 

^  APR  ProiOfHTf  PS  (0) 
gg  APR-RDP  (0) 

Q  APR-FTPSfl)) 
igl  APR-P0P3S(Ü3 
.(g  APR-IMAPSC&) 

APR-UJAPStP) 

APR-SPSÍO) 


3 


RequKtgd:  DN5  ríame 


Efflsssn 


I  Spooftng  IP  I  Spoofgd 


APR-pj^s  r 


,  Hosts  |[  ©  APR  lü  RQirtirtg  Pas$wtjrdi  VolP  1 


tosí  p^deetK  0% 


- 


Fig.  4.29.-  Petición  DNS  alterada  en  Irán  sito. 


La  siguiente  imagen  muestra  precisamente  la  secuencia  desde  el  punto  de  vista  de  la  víctinia. 
La  primera  petición ping  responde  a  la  resolución  correcta  de  la  dirección  intranet. empresa, 
es.  Tras  vaciar  la  caché,  se  produce  nuevamente  la  misma  petición  con  el  ataque  de  hombre 
en  medio  ya  lanzada.  La  resolución  en  este  caso  muestra  que  la  respuesta  corresponde  con 
otra  dirección  IP  a  la  obtenida  de  forma  previa. 
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Fig.  4.3Ü.-  Secuent;ia  de  resolución  DNS  alterada. 


^  C:\WINOOwS\#ystfim32\cmd.e3t]e  . ; 

:  v>p  in  trarse  (.  *  «mpresa ,  es 

diciendo  ping  a  intranet  í.e»pFesa_ es  Í192 .168 .0„1  j  con  -Í2  bytes  de  datos 

4r:: puesta  desde  192_16G,B,.lí  feytes=32  tienpo=lns  TTL^128 
<í; i>!C4íSta  desde  192.1S6.0»!:  feptes*32  tienpo=4ns  TTL=129 
depuesta  desde  192.168.0,lí  bvtes=32  tienpo-3ns  TTL^l^S 
<ir  puesta  desde  192.16B.0.1:  bytes  =32  tienpo=2ins  TIL «1 29 

.  i;  tt?.d  ícticas  de  pinH  paí^a  192.168.0.1: 

Paquetes:  enuiados  ^  4»  recibidos  =  4,  pei^didos  =  0 
<0ií  perdidos 

i  ienpos  aproximados  de  ida  y  vuelta  en  fiilisesundoíi: 
fíínimo  =  Ims,  Máximo  4mS:,  Media  =  2ws 

;:S>ipconfig  /flusbdns 

Jouf iguraciéfl  IP  de  Hindows 

■>.  vació  con  «xito  la  caché  de  resolución  de  DNS. 

-':\>plng  iritranet.empresa.es 

Asciendo  ping  a  intranet.empresa.es  [192 .1&Q.0_10 j  con  32  bytes  de  dato 


4.5.-  Rogue  DHCP 

Aunque  la  mayor  parte  de  ataques  vistos  están  basados  o  tienen  como  fundamento  el 
correspondiente  al  ataque  de  MITM,  existe  una  variante  que  ha  sido  ampliamente  explotada, 
basado  en  la  implementacióii  de  un  servidor  DHCP  falseado.  Si  una  organización  utiliza 
un  servidor  DHCP  para  asignar  y  ofrecer  de  fonna  dinámica  tanto  direcciones  IP  como  la 
configuración  completa  a  nivel  de  TCP/IP  del  host,  lo  hará  para  simplificar  el  esfuerzo  de 
administración  con  respecto  al  mismo. 

Sin  embargo  hay  que  tener  en  cuenta  que  la  funcionalidad  del  mismo  es  un  tanto  anárquica, 
de  tal  forma  que  la  existencia  en  una  misma  red  de  dos  servidores  DHCP  puede  llegar 
a  ocasionar  que  la  configuración  adquirida  por  una  máquina,  bien  sea  la  facilitada  por 
uno  o  por  el  otro.  Básicamente  el  que  primero  responda  a  una  petición  formulada.  El 
funcionamiento  de  dicho  servicio  en  lo  que  respecta  al  proceso  de  petición,  es  el  siguiente: 

-  El  cliente  envía  un  paquete  DISCOVERY  para  que  el  servidor  DHCP  de  dicha 
red  de  computadoras  le  asigne  una  dirección  IP  y  otros  parámetros  como  la  máscara 
de  red  o  el  nombre  DNS. 

-  A  continuación  el  servidor  DHCP  responde  con  un  OFFER  en  el  que  suministra 
una  serie  de  parámetros  al  cliente,  IP,  puerta  de  enlace,  DNS,  etc. 

-  El  cliente  selecciona  los  parámetros  que  le  interesan  y  con  un  REQUEST  solicita 
estos  parámetros  al  servidor. 
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-  Por  último  el  sen'idor  reconoce  que  se  ha  reservado  correctamente  los  parámetros 
solicitados  con  un  DHCP  ACK  y  se  los  envía  al  cliente. 


El  ataque  simple  se  basa  en  implcmentar  un  serv  idor  DHCP  falso  en  la  red,  de  tai  forma 
que  cuando  el  cliente  envía  una  trama  tipo  DISCOVERY,  responden  con  un  OFFER  tanto 
el  DHCP  real  como  el  servidor  DHCP  falso.  ¿A  quién  atenderá  el  cliente?  La  respuesta  es 
el  que  consiga  enviar  antes  al  cliente  la  respuesta  DHCP  OFFER,  En  ocasiones  podrá  ser  el 
servidor  falso  y  en  otras  el  servidor  DHCP  real.  La  imagen  siguiente  muestra  la  captura  de 
las  tramas  tipo  OFFER  que  remiten  dos  servidores  al  cliente. 


192.168.0. 190^ 

192.1680.51 

DHCP 

342  DHCP  Pelease  - 

7  ^O.O.O.Q 

255. 255. 25S. 255 

DHCP 

_ AÍ42  DHCP  piscav^  ~ 

5Cl92.16«,ÓLig7 

255.255.255.255. 

DHCP 

342  DHCP  Offer  j  " 

o  0.0.0. 0 

255,255.255.255? 

OHCP 

352  DHCP  neauest  ~ 

5(192.168.0.51 

235.255,255.255 

DHCP 

328  DHCP  Off er  ^  - 

3  192. 16S,  0-197 

255.253,255.255 

DHCP 

342  DHCP  ACK 

0  192, 16S.  0.51 

255-  255.  2SS.  255 

DHCP 

328  DHCP  ACK 

Fig.  4,3  ]  -  Respuesta  ofrecida  por  dos  sen  idores  DHCP. 


Un  problema  fundamental  para  e!  atacante,  es  que  éste  desconoce  inicial  mente  tanto  el 
rango  de  direcciones  IP  que  se  conceden,  como  las  que  se  encuentran  ya  asignadas  por  el 
servidor  DHCP  real.  De  esta  forma  podría  existir  un  conflicto  entre  las  direcciones  IP  que 
da  el  falso  servidor,  con  las  dadas  por  el  servidor  real  Para  evitar  este  problema  existe 
la  posibilidad  de  ofrecer  solo  determinado  tipo  información  de  configuración  de  hosl:  el 
ataque  DHCP  ACK  injection. 

Dado  que  toda  la  comunicación  DHCP  se  realiza  enviando  los  paquetes  a  la  dirección 
MAC  de  bmadeast  FF:FF:FF:FF:FF:FF  todos  los  clientes  de  la  LAN  reciben  los  paquetes 
DHCP.  De  esta  forma  existe  la  posibilidad  de  que  un  atacante  monitorice  los  intercambios 
DHCP  y  en  un  determinado  punto  de  la  comunicación  envíe  un  paquete  especialmente 
fonnado  para  modificar  su  comportamiento. 

Uno  de  los  puntos  donde  interesaría  intervenir  es  cuando  el  servidor  reconoce  con  un  DHCP 
ACK  la  configuración  del  cliente.  Primero  se  tiene  que  escuchar  toda  la  comunicación 
poniendo  atención  en  el  paquete  REQUEST  donde  el  cliente  solicita  la  IP,  DNS  y  Gateway 
entre  otros  de  aquellos  datos  que  anteriormente  le  ha  ofrecido  el  ser\ddor  DHCP.  Una  vez 
recibido  el  REQUEST  podría  responderse  con  un  ACK  como  lo  baria  el  servidor  DHCP 
real  pero  estableciendo  la  configuración  a  criterio  del  atacante. 

La  siguiente  figura  muestra  como  se  produciría  la  transición  de  tramas  para  hacer  efectivo 
el  ataque. 
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Client 


server 


t"  unlc»A 
>^firtJOWLED<jg. 


Fake  response 
Real  DHCP  Server 


Fig.  4.32.-  Ataque  DHCP  ACK  Injection. 


La  ventaja  de  este  ataque  es  que  no  se  necesita  conocer  el  rango  de  direcciones  iP  válidas  ni 
que  direcciones  están  libres  y  cuales  ocupadas.  Se  deja  en  manos  del  servidor  DHCP  real  el 
que  ofrezca  toda  esa  información  y  sólo  se  interviene  en  la  fase  final,  en  el  reconocimiento 
que  da  el  servidor  sobre  la  configuración  seleccionada.  También  es  más  difícil  de  detectar. 
Solo  se  envía  un  paquete  y  este  puede  ser  enviado  con  la  TP  suplantada  del  servidor  DHCP. 


Fíg,  4.33.- Aplicación  para  la  realización  del  ataque  DHCP  ACK  fnjection. 


Capitulo  IV.  Atacando  por  capas 


71 


l  ig.  434-  Captura  de  tramas  ACK. 


Sin  embargo  como  en  el  anterior  escenario  existe  la  posibilidad  de  que  la  respuesta  proceda 
tanto  del  atacante  como  del  servidor  DHCP  real  y  e!  cliente  solo  hará  caso  al  primero 
de  ellos  que  responda*  Algunas  veces  será  más  rápido  el  servidor  DHCP  real,  otras  el 
atacante.  Para  automatizar  este  ataque  en  Infarmütica64  se  ha  desarrollado  una  aplicación 
desarrollada  en  C#.  Para  su  ejecución  será  necesaria  tener  instalado  el  .NET Framework3J, 
La  anterior  imagen  muestra  el  intercambio  de  tramas  recogido  por  ffirei/zíjrA:  donde  quedan 
remarcados  los  dos  paquetes  de  tipo  ACK,  remitidos  por  el  servidor  real  y  la  aplicación 
encargada  de  realizar  el  ataque.  Tal  y  como  puede  observarse,  la  dirección  TP  de  ambas 
tramas  es  la  misma,  pero  no  así  la  dirección  fisica.  Cuestión  no  obstante  que  no  es  validada 
por  los  sistemas  víctimas.  En  los  detalles  del  protocolo  DHCP  en  la  trama  de  tipo  ACK 
pueden  verse  los  valores  falsos  enviados  a  la  víctima  por  parte  de  la  aplicación  atacante* 


De  esta  forma  eí  atacante  no  tendrá  que  tener  conocimiento  ni  de  las  IP  dadas  ni  de  las  que 
pueden  ofrecerse,  solo  se  facilitarán  los  parámetros  necesarios  para  interceptar  por  ejemplo 
los  paquetes  dirigidos  al  router  o  plantear  la  base  para  un  ataque  de  DNS  Spoofing. 
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COGkiet  OHCP 

S  optiofí:  (t-53,1-1)  WCP  Typ«  •  OHCP  ACK 

i5  opt1<>n:  Ct-^p1-4)  D«cp  Serv^  Ide(^ct^f -ler  *  X92.16B.0. Si 
-$  optfoni  IP  Address  L^Ase  Time  -  1  day 

a  Optl^:  ft-l.l-JS  Subnet  wask  -  Z5S.  2S5.  2SS.0 
íi  option:  Ct»3 » 1  ^  5ARoiit  er  -  1^2 .  IfiS.  0.  ISO 
S0  option:  CT*6pl-4Í^Ooma1h  lyaae  server  «  192*  168. 0. 19oJ 
End  QptíOft _ 


Fig.  4.35.-  Detalles  tráma  ACK. 


Como  mecanismo  de  defensa  pueden  encontrarse  aplicaciones  tales  como  DHCP  Prohe^ 
que  cotejan  en  una  base  de  datos  los  servidores  DHCP  legales  que  se  habrán  introducido, 
con  el  tráfico  generado  por  un  falso  servidor  DHCP.  Dicha  aplicación  lanza  peticiones 
de  DHCP  evaluando  la  respuesta  obtenida,  indicando  para  ello  que  servidores  son  los 
legítimos  y  cuáles  no* 


|deb’ig 

debug 

d€bug 

debug: 

debug 

debug 

debug 

debug 

debug 

debug 

debug 

debtig 

Idebug 

|debug 

debug 

debug 

debug 

warn : 

th  IP 


to  íf:ff ;ff 


startirig  new  cycle 
¥JritiRg  packet  4 

listeí>ing  for  answers  for  miUisecancis 
capturad  a  packet 

interface  etbe,  froFJ  ether  5c:d9:9S; 
from  IP  192.168.0,51  to  255.255.255.255 
this  is  a  J egal  f j rye r  i_  igno r i ng 
done  listening,  capttired  í  packeifs 
wríting  packet  3 

lisTening  for  ^nswers  for  seee  ínílliseconds 
done  lístening,  captured  @  packets 
writing  packet  I 

listening  for  answers  for  5M0  uiiUisecontís 
captured  a  packet 

interface  etb©,  fropu  ether  0;lc:bf 
frOiTt  IP  192.168.0.51  to  255.255.255.255 
ether  sbost  0:lC;bf:;'>v^^’  is  net  a  legal  server 
received  unexpected  reVponse  on  irterfáce  eth0  f rom  BootP/DHCP  server  w; 
source  192.168.9.51  íether  src  0 atíbf 


to  ff:ff.'ffíff:ff:ff 


Fig.  43(>.- DHCP  Probe. 


Tal  y  como  se  ha  visto  los  ataques  sobre  las  redes  de  dalos,  constituyen  un  problema  que 
debe  ser  muy  tenido  en  euenta  por  las  organizaciones.  De  una  u  otra  forma  deberá  ser 
paliado,  bien  aplicando  contramedidas  contra  los  ataques  o  contrarrestando  su  eficacia 
mediante  el  ciliado  de  la  información.  Cualquier  acción  a  llevar  a  efecto  será  mejor  que 
no  tomar  medidas.  Las  hay  más  o  menos  efectivas.  Algunas  dependen  simplemente  de  la 
buena  voluntad  o  intuición  del  que  opera  o  maneja  un  sistema.  Los  siguientes  capítulos 
tendrán  en  euenta  y  mostrarán  diferentes  mecanismos  de  protección.  La  eficacia  de  los 
mismos  dependerá  de  muchos  factores  y  quizás  solo  la  suma  de  varios  proporcione  la 
solución  efectiva.  Sin  embargo  hay  que  tener  en  cuenta  que  esto  es  una  constante  evolución 
y  que  la  aplicación  de  técnicas  de  defensa  no  es  en  absoluto  atemporal.  Hay  que  recordar 
que  cuando  surgió  la  especificación  del  protocolo  ARP  no  se  atisbaba  la  posibilidad  de  la 
existencia  del  ataque  de  hombre  en  medio. 
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Capítulo  V 

Ataques  en  redes  de  datos  IPv6 


Ataques  en  redes  de  datos  IPv6 

Cada  vez  son  más  las  noticias  de  fallos  de  seguridad  y  herramientas  de  hacking  centradas 
única  y  exclusivamente  en  el  protocolo  IPv6.  Hay  que  tener  presente  que  aunque  la 
implemeetación  de  IPv6  parece  muy  reciente,  la  definición  del  mismo  ya  tiene  algún 
tiempo,  concretamente  empezó  a  fraguarse  en  el  año  1 995  a  través  de  la  RFC  1 883.  Es 
cierto  que  la  definición  final  de  las  especificaciones  lleva  tiempo  y  hay  que  adaptarlas 
constantemente,  pero  con  la  velocidad  con  la  que  evolucionan  tanto  las  comunicaciones 
como  los  entornos  IT,  esto  representa  mucho  tiempo. 

Además  ha  sido  necesario  un  proceso  de  maduración  de  estas  tecnologías  dentro  del 
desarrollo  de  productos,  y  a  lo  largo  de  los  años  hemos  visto  muchos  bugs  de  gran  seriedad 
dentro  de  estas  tecnologías.  El  primer  gran  escándalo  sobre  un  BUG  en  lPv6  dentro  del 
mundo  del  hacking  tuvo  como  protagonista  a  las  empresas  CISCO,  Internet  Security 
Systems  y  el  hacker  Michael  Lynn. 

La  historia  comenzó  con  un  BUG  parcheado  por  CISCO  en  Abril  de  2005  en  la 
implementación  de  la  pila  IPv6  de  sus  routers.  Sin  embargo,  según  el  investigador  de 
seguridad  Michael  Lynn  que  trabajaba  en  la  empresa  de  seguridad  ISS  {Internet  Security 
Systems),  la  información  que  CISCO  había  publicado  sobre  el  BUG  no  era  toda  verdad  y 
el  riesgo  era  mucho  mayor.  Michael  Lynn  encontró  la  forma  de  tomar  el  control  total  de 
los  routers  con  soporte  tPv6  de  CISCO  y  quería  hacer  una  demostración  en  BlackHat  USA, 
algo  que  no  gustó  mucho  a  CISCO. 

Al  principio  ISS  aprobó  la  charla  de  Michael  Lynn,  pero  tras  presiones  de  la  empresa  CISCO 
una  vez  que  se  había  anunciada  la  charla  en  la  agenda  de  BlackHat  USA,  la  empresa  ISS 
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decidió  prohibir  la  presentación  y  mandarle  que  diera  una  charla  genérica  de  seguridad  en 
el  sistema  operativo  IOS,  obligando  a  que  se  quitaran  de  la  bolsa  de  documentación  que  se 
entrega  a  todos  los  asistentes  a  las  conferencias  BlackHat  los  DVDs  con  el  whitepapery^»^ 
diapositivas  de  la  charla  grabadas  en  él,  y  que  se  arrancaran  las  páginas  con  el  whitepaper 
del  libro  de  presentaciones.  El  vídeo  con  el  momento  de  la  censura  del  libro  dio  la  vaielta  a 
Internet  y  se  convirtió  en  un  icono  de  las  charlas  de  aquel  año. 

Al  final  Michael Lynn  dio  la  charla  explicando  en  profundidad  el  BUG  en  lPv6  y  la  forma  de 
explotarlo,  algo  que  llevó  a  que  fuera  demandado  por  CISCO,  ISS,  y  se  denunciaran  a  todos 
los  que  publicaran  alguna  infomiación  de  aquel  fallo  o  las  presentaciones  de  la  conferencia, 
montándose  un  gran  debate  sobre  el  ""Responsible  Disclosure"  en  aquella  época. 


Richard  Romo 

EmaH:  x2@lnfowafrior.org 

Fax  (US)  25J-793.3166 

Dear  Mr.  Romo: 

I  am  sn  attomey  at  OLA  Rper  Ruetni^  Oray  Cary  US  LLP  and  represent  Internat  Sacurfty 
Systents,  Inc  fiSS').  I  wilte  to  bifoitn  you  that  you  are  currertOy  hostirig  website  contení  that 
oontains  proprietary  Information  of  tSS  that  was  slolan  a  formar  ampioyee.  Wa  demand  that 

you  taKe  down  the  postátg  immediateiy. 

Tha  postlng  is  located  ort  your  website  at  http7/www.infowarrk>r.orgA;serb/FfomQ/lynn-cisco.pdf 
atxl  relates  to  a  presentatton  that  IS3  deddad  nol  go  gtve  at  bie  Bladt  Hat  2005  USA 
Conferenca  ín  Las  Vagas,  Nevada.  Michaal  Lynit  (who  tamnirtated  hts  emptoymant  with  ISS  on 
Wadnesday)  was  not  authorized  to  tato  and  distrtbute  it  and  Hat.  to  tha  axtent  it  had  tha 
presentation,  waa  under  an  oblígation  to  toep  it  oonfldenüal. 

On  Wednasday.  iSS  and  Cisoo  sued  Mr.  Lynn  and  Black  Hat  for  daims  of  copyright 
•nfnng«T»ent.  mísappnopriation  of  trade  Gocrets,  and  breach  of  empioymdnt  agreamant  ín 
connaction  with  improper  dlstrtbution  of  ihe  material.  On  Thur&day,  dudge  Jaffray  Whíte  ol  tha 
United  Stated  Dietrict  Court  fbr  tha  Northern  Oiatrlci  of  California  tesued  a  parmanent  ir^unctlofl 
praventing  furthar  distrlbution  of  tha  matariat  (attachad).  Ctaco  SysfamG^  Inc.  and  Intamat 
Secudfy  Systems.  Inc.  v.  Mtchaef  Lynn  and  Bidcfr  Hat  Inc.  Untod  S»tes  DIstilct  Court.  Northern 
District  of  Califomia. 

We  atso  understand  that  tha  uniawful  distribution  of  this  Information  is  ihe  subjact  of  a  íadarai 
inveatigation. 

We  damand  that  tha  posUng  be  taton  down  immediateiy.  If  día  poGting  is  not  wlthdrawn 
immadlataty,  ISS  will  be  forcad  to  pursua  Its  legal  remedies.  Ptease  immediateiy  confirm  by 
email  responso  or  phonc  by  12:00  p.m.  PDT,  July  30, 2005.  that  ihe  posüng  has  been  removed. 

Thank  you  for  your  ardeipated  oooperatlon  In  this  regard.  i  loolc  fotward  to  your  prompt 
raspottse. _ 


Frg.  5.I.-  Correo  de  amenaza  de  denanda  por  publicar  información  del  BUG  IPvó  de  CISCO. 
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No  hay  que  irse  tan  atrás  en  el  tiempo  para  ver  casos  similares  a  este  de  CISCO  con  fallos 
de  software  por  culpa  solo  de  la  implementación  de  la  solución  en  la  pila  de  protocolos 
TPv6,  como  vamos  a  ver  a  continuación. 

En  el  año  2013  la  suite  de  seguridad  Kaspersky  Internet  Securíty  2013  sufrió  un  BUG  que 
permitía  a  un  atacante  remoto  bloquear  todo  equipo  que  tuviera  instalado  ese  software  por 
medio  de  la  herramienta  /ímv¿í//6  de  THC  que  se  comentará  más  adelante  en  este  mismo 
capítulo. 

Con  esta  vulnerabilidad  de  seguridad  basta  con  enviar  una  serie  de  pruebas  a  cualquier 
puerto  con  los  parámetros  18,  19,  20,  y  21  para  que  el  equipo  queda  totalmente  bloqueado, 
con  el  siguiente  comando: 

-  fírew^alló  <interface>  <target>  <port>  1 9 

-  firewalló  <interface>  <target>  <port>  20 

-  ílrew  alló  <interface>  <target>  <port>  21 

-  firewalló  <interface>  <target>  <port>  22 

Este  fallo  permitía  que  se  hicieran  ataques  de  Remate  Dental  qf  Service^  al  estilo  de  los 
viejos  nukeadores  de  red  que  baneaban  a  los  equipos  de  servicios  o  crasheaban  el  sistema 
a  través  de  la  red  con  el  clásico  Ping  of  Death. 


También  otro  proyecto  mítico  dentro  de  los  sistemas  el  proyecto  SUDO  que  se 

utiliza  para  limitar  el  uso  de  privilegios  de  administrador  en  los  sistemas,  se  vio  afectado 
por  un  fallo  al  impl ementar  el  soporte  para  TPv6.  El  problema  vino  por  cómo  se  había 
configurado  el  tratamiento  de  los  hosts. 

La  descripción  de  un  host  o  de  varios  en  una  host  lisí  puede  hacerse  basada  en  el  nombre 
del  equipo,  su  dirección  IP  o  la  dirección  de  red  de  varios  equipos  junto  con  su  máscara  de 
red.  Cuando  el  módulo  no  encuentra  ninguna  coincidencia  en  la  lista  de  direcciones  IPv4, 
prueba  con  TPv6,  y  es  posible  que  en  ciertas  cireunstancias,  un  equipo  con  una  dirección 
lPv6  sea  reconocido  como  una  dirección  lPv4  permitida,  por  la  forma  en  que  se  evalúa  el 
fichero. 

El  BUG^  se  produjo  porque  se  habían  olvidado  de  añadir  una  instrucción  break  al  selector 
swítch,  lo  que  hacía  que  después  de  ejecutar  el  código  para  lPv4,  si  no  había  ninguna 
coincidencia,  siguiera  con  las  condiciones  lPv6  aunque  la  dirección  fuese  una  dirección 
lPv4. 
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SMUch  (r«A|tu>  { 
c««  HF_INETi 

ii  ((lfp»>«df]r  ti  ^sk.lp^.s^^ddr)  jMidr ai»V 

ct^g^rtlurA.bMl  (truc)  % 

Ct»  «V^lNET6t 

for  (J  •  d|  j  <  (#ddr .£p6.si-*ddr) I  J**>  ( 

((ifp*>*dclr.ip6»s$.44cir{j)  -ipS.^S^wSdrf  j))  I»  MNlr.Íp$.s8.*c}dr{J] ) 

bTftftki 

X 

if  (J  «  sl£*or(4<fdr  apé^sS^whlr)) 
d€tH>g^rttiirf^bool  (ir^bc}  I 

br««k| 


Fig.  5.2.-  Código  de  ¿"L'Z^O  vulnerable  al  no  dilferenciar  IPv4  de  lPv6. 


El  parche  para  este  fallo,  fue  tan  sencillo  como  añadir  una  instrucción  break  al  final  del 
código  de  tratamiento  de  direcciones  lPv4,  lo  que  evitaría  que  el  softv^^are  confundiera  una 
dirección  IPv4  como  una  dirección  IPv6  en  ninguna  circunstancia. 


SüUch  (f«NÍi||>  { 
iir.IIIETi 

if  {(ifp^>«d<^.ip^.s^#<fdr  ti  m%^  Aph.%^%4ár}  mm  #iSdr *lp4 
<i«bug^rÉ  turn^&dol  ( triMi  >  I 

br<#kj 

foi-  (J  •  ii  J  <  siEeaí(«d^.lpS.it^«<klr)|  J*#)  í 

if  (<lfp">*ddr.ifi6.96-*(kJir{J)  ti  A»9li.ipe.s6.*dKir{J])  1-  «ddr .lf>S.iS.A0dr( J] } 
break I 

) 

If  (J  sizeof(«<klr.£pS,s$.»44r)} 

<f€bM0*r«tiirn.lK»ot  ( trii«>i 


Fig.  5.3.-  Código  del  proyeelo  SUDO  parchcado  con  la  instrucción  breaL 


Uno  de  los  grandes  problemas,  es  que  la  gran  mayoría  de  los  sistemas  -  al  igual  que  los 
ejemplos  de  fallos  en  software  presentados  -  no  contemplan  IPv6  dentro  de  los  posibles 
vectores  de  ataque,  por  lo  que  las  medidas  de  seguridad  de  red  siguen  ancladas  en  detectar 
ataques  sobre  IPv4. 

Muchas  soluciones  detectan  ataques  ARP-SpooJmg,  pero  sin  embargo  no  aplican  ninguna 
protección  contra  los  ataques  de  — ataques  equivalentes  en  TPv4  e  IPv6 

La  electrónica  de  red  también  es  importante,  pues  como  veremos  más  adelante,  ataques 
como  la  denegación  de  servicio  basada  en  tormentas  de  mensajes  de  Router  Advertisement 
o  el  ataque  man  in  the  middie  basado  en  el  protocolo  SLAAC necesitan  de  una  configuración 
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robusta  de  los  puertos  de  un  switch,  por  lo  que  es  necesario  contar  con  hardware  de  una 
granularidad  especial  que  permita  limitar  por  qué  bocas  se  pueden  enviar  mensajes  RA  o 
RS, 

Por  último,  también  es  muy  importante  el  tactor  humano,  ya  que  muchos  administradores 
aún  no  piensan  que  lPv6  esté  definitivamente  en  su  red,  y  ese  es  el  mayor  de  los  problemas 
y  la  mayor  de  las  ventajas  para  un  atacante,  lPv6  está  en  casi  todas  las  redes,  y  puede  ser 
explotado. 

Antes  de  explicar  en  detalle  cada  uno  de  los  ataques  se  va  a  hacer  un  buen  repaso  a  los 
conceptos  necesarios  que  hay  que  manejar  para  entender  todos  y  cada  uno  de  los  ataques 
que  van  a  ser  descritos  sobre  IPv6. 


5.1.-  Conceptos  básicos  sobre  IPv6 

El  protocolo  lPv6  lleva  ya  mucho  tiempo  entre  nosotros,  y  aunque  aún  mucha  gente  se 
empeña  en  revisar  las  configuraciones  IPv4  en  una  red  de  empresa,  lo  que  realmente  está 
funcionando  en  muchos  entornos  en  conexiones  SMB^  DNS  o  incluso  la  wxb  de  la  Intranet ^ 
es  protocolo  IPv6.  Conocer  su  funcionamiento  es  fundamental  para  la  protección  de  una 
red,  ya  que  muchos  de  los  sistemas  de  protección  IDS  están  configurados  para  detectar  la 
mayoria  de  los  ataques  en  redes  IPv4,  pero  no  hacen  lo  mismo  con  los  ataques  lPv6. 

Esta  parte  se  va  a  centrar  en  los  conceptos  básicos  de  este  protocolo,  que  debería  haber 
entrado  hace  mucho  tiempo  en  nuestra  vida  cotidiana,  y  sin  embargo  sigue  siendo  un  gran 
desconocido  para  muchos  técnicos,  a  pesar  de  que  al  realizar  un  ipeonfig  salga  esa  dirección 
feSO::  al  principio  de  todo. 


5.1.1-  Probando  IPv6  en  la  red 

Para  comprobar  de  forma  práctica  que  un  sistema  Microsoft  Windows  utiliza  lPv6  por 
defecto  en  una  red  local  cualquiera  -  depende  mucho  de  la  configuración  del  DNS  dentro 
de  la  misma  y  que  según  la  configuración  de  la  infraestructura  de  red,  por  defecto,  tiene 
prioridad  sobre  el  protocolo  lPv4,  se  puede  hacer  una  prueba  muy  sencilla,  pero  que  a 
muchos  sorprende  -  y  que  deberías  hacerla  por  ti  mismo  si  aún  no  has  tomado  concieocia 
del  riesgo  de  tener  TPv6  sin  configurar  correctamente  en  tu  red 
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La  prueba  es  tan  sencilla  como  realizar  la  ejecución  de  un  simple  comando  Píng  entre  dos 
equipos  Windows  en  la  red  con  la  configuración  por  defecto,  para  coinprobar  que  lPv6 
prevalece  sobre  lPv4. 

Paso  l :  Primero  se  debe  hacer  un  ipconfig  en  uno  de  los  equipos  Windows^  para  que  se  vea 
que  existe  la  dirección  IPv6  de  vínculo  local.  Las  direcciones  de  vínculo  local,  como  explica 
un  poco  más  adelante,  siempre  están  asociadas  a  las  taijetas  cuando  lPv6  está  activado,  y 
pertenecen  a  la  red  efectiva  fe80::/64.  Si  sale  esa  dirección,  entonces  continúa  con  el  paso 
2  para  completar  !a  prueba. 


údaptador  de  Ethei*net  Conexión  de  área  local: 
ííuf  iáti  IJNS  específico  La  conexión*  .  : 

Uíncttlo:  dirección  1  FmE  local*  *  *  :  f  oBít :  :  f  dVc  :  bB:H  t 

Dirección  .  *  :  192-160*1.204 

de  subred  . :  2SS  *  2SS  *  *  0 

Puerta  de  enlcvce  por detern inada . :  t  9:!  .  Hd]  .  !  .  i _ 


Fig.  5,4  -  Dirección  IPv6  de  enluce  locul  en  una  confisuración  por  delecto. 


Paso  2:  Dentro  del  mismo  segmento  de  la  red  se  hace  un  Píng  a  una  dirección  lPv4  de  algún 
otro  equipo.  Es  importante  que  esté  en  el  mismo  segmento  de  red,  porque  por  defecto  lPv6 
no  viene  configurado  con  default  Gateway  y  las  direcciones  de  vínculo  local  IPv6,  además, 
no  son  enmtabies.  Para  averiguar  e!  nombre  del  equipo,  se  debe  utilizar  el  modificador  ~a 
del  comando  Ping. 


C :  \llse  rs\user>ping  -d  192-168-0*1 

ilaciefidtt  pifiq  arís^ruíír  f.l  92  *  cor*  bytes  de  datos: 

PespLtesia  de s de Hri':?rr¡3rí5^^  tienpn  Inc  TIL  128 

Respuesta  desde  192.168-0-1:  b.ytes-32  tier>po<ln  TIL -128 
Respuesta  desde  192.168.0-1:  bytes-32  tienpo<lri  TIL  128 
Respuest¿t  desde  192.168*0.1:  bytes  "32  tienpa-íns  TTL  128 

¡Estadísticas  de  ping  para  192*168.0*1  : 

Pilque  tes;  enviados  4^  recibidos  4.  perdidos  ^  0 
i  <02  perdidos). 

Tiempos  apraxinados  de  ida  g  vuelta  en  nilisegundos : 

Hínirio  -  0ris ,  Haximo  "  Tris,  Media  ■-  Iris 


Fig.  5.5 r-  Píng  'U  a  una  dirección  IP  del  misino  segmento  de  red. 


Paso  3:  Una  vez  hecho  eso,  se  debe  hacer  simplemente  un  Ping  al  nombre  NetBIOS  del 
equipo  que  ha  salido.  No  se  debe  hacer  al  FQDN  por  si  solo  hay  un  servidor  DJSS  en  la  red 
TPv4.  Esto  hará  que  el  protocolo  LLMNR  -  que  se  explica  un  poco  más  adelante  -  busque 
por  toda  la  red  todas  las  direcciones  lPv4  e  lPv6  asociadas  a  este  hosíname,  buscando  los 
registros  A  y  AAAA  usando  los  DNS  en  IPv4  e  IPvó  -  los  dos  tipos  de  registros  en  los  dos 
ser\  idores  “  y  la  difusión  broadeasí.  Si  todo  ha  ido  bien,  te  habrá  contestado  el  equipo,  pero 
desde  la  dirección  ÍPvó. 
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C:\UseFi;  Vise  sei*viíi* 

jHftciendo  piny  «t  f  ¿  eV‘ Y  F  <?  8  tí  :  :  S  d0f>  ^  f  J.  3  f  :  de  bi  :  279  1 2  Tic  o  n  32  h(*ftes  de  drttü 

ÍRtíspiiervta  de?^de  TeWTTSts^TrTO^ 

[Respuesta  desde  f  e,0feí:  ;*id0íi  *  f  I3f  :  dchl  :2?9axl2  s  tienptKlm 
jRespuesta  desde  f  eSíí :  líidftfj  if  l3f  *  deht  í  :  tiéf^pu<lFi 

jlíespaestA  desde  f  e8tl:  :Sdí!í> :  f  1 3f  :dcbl  í2?9í^212  :  tiei'ipoClw 

1  í  tad  íst  icas  de  piivg  para  f  e80 ;  :  SdSb  :  f  1 3f  :  dcM  :  27?a>:12  : 

Paquetes;  eneiadoít  4^  recibidos  ^  4,  perdidos  “  0 
C0X  perdidos), 

[  ienpDs  api'óxinados  de  ida  y  oue  Ita  en  niliseaiindes ; 

Híniítie  “  0ns ,  Háxine  Ifrjs ,  Media  - 


Fig.  5.6.-  Fmg  al  nombre  del  servidor  utiliza  lPv6. 


Si  esto  ha  dado  positivo  entonces  será  posible  realizar  ataques  de  Neighhor  Spoofmg  en 
lPv6  para  robar  ficheros  SMB  y  no  servirá  de  nada  que  haya  controles  en  la  tabla  ARP,  ya 
que  todo  el  ataque  tiene  efecto  en  las  estructuras  de  IPv6. 


Si  te  ha  dado  negativo,  no  quiere  decir  que  IPv6  no  esté  en  tu  red.  Lo  más  probablemente 
es  que  si  haces  un  análisis  de  tráfico  de  red  con  Wireshark  es  que  el  equipo  esté  conectado 
a  una  red  corporativa  y  se  esté  añadiendo  el  sufijo  de  búsqueda  DNS  para  construir  un 
FQDN,  y  que  el  equipo  esté  dado  de  alta  en  el  DNS,  haciendo  que  solo  se  comuniquen  por 
lPv4.  Aun  así,  los  ataques  de  red  en  IPv6  continuarán  teniendo  efecto  si  tienes  el  protocolo 
activado. 


5.1.2.-  Configuración  básica  de  IPv6  en  sistemas  Microsoft  Windows 

Antes  de  comenzar  a  explicar  en  detalle  los  ataques  que  se  pueden  realizar  en  una  red 
sobre  la  capa  de  protocolos  lPv6  es  necesario  tamil iarizarse  con  todos  los  conceptos 
fundamentales  de  esta  familia  de  protocolos,  así  que  habrá  que  asentar  algunas  cosas  al 
principio  para  que  se  puedan  entender  correctamente. 

Si  entramos  en  las  propiedades  del  protocolo  IPv6  de  un  sistema  Microsoft  Windows,  lo 
primero  que  encontraremos  es  una  pantalla  de  configuración  más  o  menos  similar  a  la  de 
IPv4,  con  la  única  diferencia  de  que  las  direcciones  IP  serán  de  128  bits,  que  se  escriben  en 
hexadecimal  separadas  en  grupos  de  16  bits,  es  decir,  cuatro  valores  hexadecimales. 

Esto  hace  que  las  direcciones  TPv6  queden  escritas  de  una  forma  similar  a  feSO;  123:0000: 
0000:0000:0000:0000:  labO  y  que  los  administradores  y  técnicos  de  sistema  informáticos 
menos  acostumbrados  a  esta  forma  de  denotar  la  dirección  de  un  equipo  en  la  red  le  suene 
extraño  y  complicado.  Es  un  poco  más  raro  al  principio  si  tienes  mucha  experiencia  en  IPv4, 
pero  no  lo  será  tanto  cuanto  te  acostumbres  a  esos  8  grupos  de  4  valores  hexadecimales. 
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Fig.  5  7.-  Ejeinpjo  de  configumciÓTi  de  IPv6  en  Windows. 


Para  que  sea  más  fácil  de  escribir  y  recordar,  cuando  hay  una  lista  de  grupos  de  cuatro  ceros 
seguidos,  se  puede  utilizar  el  acortador  reduciendo  la  dirección  anterior  a  algo  como: 
fe80:]23::lab0.  Esta  reducción  se  puede  utilizar  una  única  vez  por  cada  dirección  lPv6  y 
solo  para  grupos  de  4  ceros  consecutivos.  Es  por  eso  que  será  muy  común  encontrar  cosas 
como  fc00::l  en  una  dirección  IPy6  de  una  red  privada* 

En  segundo  lugar,  aunque  no  se  llama  máscara  de  red,  tenemos  algo  muy  similar  llamado 
Prefijo  de  Subred.  Este  término  se  ha  cambiado  debido  a  las  cantidades  de  problemas  que 
causó  en  muchos  usuarios  e  implementaciones  de  lPv4  el  uso  de  subnetting,  supemetting 
o  la  asignación  de  máscaras  de  red  del  tipo  255. OJ  24.255,  algo  que  fue  permitido  por  el 
estándar  -  y  por  tanto  en  algunas  implementaciones  pero  que  no  acababa  de  tener  mucho 
sentido  y  volvía  loco  a  muchos  técnicos  cuando  descubrían  su  existencia. 

En  IPv6  el  prefijo  tiene  la  misma  función,  gestionar  la  visibilidad  de  red  y  utilizarse 
para  hacer  subnetting  y  supemetting,  pero  todos  los  unos  van  seguidos  y  al  principio  por 
definición  en  el  estándar*  De  esta  forma,  si  tuviéramos  dos  direcciones  lPv6  -  sin  utilizar 
una  Puerta  de  Enlace  en  la  red  -  tales  como  estas: 
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-  A:fc00::20()():()()01/96 

-  B:fc00::200 1:000 1/1 12 

Al  hacer  un  Fing  en  IPv6  de  A  a  B  obtendríamos  un  Time-Out  y  al  hacer  un  Ping  de  B  a  A 
tendríamos  una  respuesta  de  Host  inaccesible,  debido  a  que  A  no  entra  dentro  de  la  misma 
red  que  B,  pero  B  si  está  dentro  de  la  misma  red  que  A* 

Para  interconectar  las  redes  IPv6,  igual  que  en  lPv4,  hay  que  utilizar  una  Puerta  de  Enlace  o 
Gateway,  qne  se  configura  en  las  propiedades  del  protocolo  de  red,  igual  que  los  servidores 
lPv6  que  se  van  a  utilizar  para  la  resolución  de  nombres. 

Estos  servidores  DNS  no  son  los  que  se  van  a  útil  izar  para  resolver  los  nombres  a  direcciones 
IPv6  sino  que  serán  los  servidores  DNS  que  se  utilizarán  para  resolver  todo  cuando  se 
utilice  el  protocolo  IPvó,  es  decir,  también  se  utilizarán  estos  servidores  cuando  haya  que 
resolver  un  registro  DNS  de  tipo  A  cuando  se  utilice  en  la  red  local  el  protocolo  lPv6. 


5.1 .3.-  Direcciones  de  Vínculo  o  Enlace  Local  en  IPv6 

Conocidos  los  parámetros  a  configurar  en  una  conexión,  hay  que  entender  también  que  en  la 
familia  de  protocolos  IPv6,  tanto  si  se  realiza  una  configuración  manual  de  las  direcciones 
IPv6  como  si  se  deja  en  modo  Automático  -  configuración  por  defecto  en  todos  los  equipos 
con  Microsoft  Windows  (a  partir  de  la  versión  de  Windows  Vista)  y  versiones  de  MACOS  X 
-  las  tarjetas  de  red  con  soporte  para  IPv6  tendrán  asociada  una  dirección  de  IPv6  conocida 
coo  de  vínculo  local. 

Esta  dirección  se  genera  de  manera  automática  por  el  propio  equipo  y  es  anunciada  por  la 
red  cuando  se  crea  para  evitar  la  duplicidad  de  la  misma  en  la  red  en  la  que  esté  conectada 
usando  el  protocolo  NDP  (Neighhor  Discovery  Protocol). 

Esta  duplicidad  de  direcciones  no  debería  darse  de  forma  habitual,  ya  que  el  algoritmo  de 
generación  de  la  misma  depende  de  la  dirección  MAC  de  la  tarjeta  física  de  red,  pero  para 
evitar  cualquier  situación  indeseada  -  ya  que  la  posibilidad  de  MAC  duplicada  existe  por 
varios  motivos  -  se  hace  uso  de  un  sistema  que  garantice  su  unicidad  y  que  resuelva  estos 
confíictos. 

Esta  dirección  es  del  rango  fe80::/10  y  es  equivalente  al  rango  169.254.1  ,X  -  169.254.254.X 
de  IPv4.  La  única  diferencia  es  que  en  la  práctica  las  direcciones  169.254.X.X  no  se  suelen 
utilizar  en  lPv4  y  en  IPv6  estas  direcciones  se  van  a  utilizar  con  mucha  frecuencia. 
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Fig.  5.K.-  Configuración  por  defecto  en  AÍ4C  OS  X. 


Por  supuesto,  estas  direcciones  no  son  enrutables,  pero  sí  que  son  utilizadas  para 
comunicarse  con  el  router  o  para  hacerlo  con  cualquier  ser\'idor  o  equipo  de  la  organización 
que  se  encuentre  en  la  misma  red  local  en  la  que  esté  conectado  el  equipo  que  inicia  la 
comunicación. 


Si  no  se  ha  Locado  nada  de  la  configuración  por  defecto,  se  tendrá  una  de  estas  direcciones 
de  vínculo  local  asociada  a  todas  y  cada  una  de  las  taijetas  en  las  que  se  haya  habilitado 
el  protocolo  lPv6.  Por  tanto,  se  podrá  utilizar  para  hacer  por  ejemplo  un  comando  Ping  a 
cualquier  equipo  de  la  red  local  con  una  dirección  IPv6  también  de  Vinculo  o  Enlace  Locaf 
tal  y  como  se  ha  visto  anteriormente. 

Por  ejemplo,  en  la  siguiente  imagen  se  puede  ver  como  el  protocolo  SMB  utilizado  para 
compartir  archivos  e  impresoras  en  redes  Microsoft  Windows  puede  ser  utilizado  para 
acceder  a  los  recursos  compartidos  de  un  servidor  mediante  la  dirección  lPv6  del  servidor 
donde  se  comparte  ese  recurso. 


Para  ello  el  acceso  vía  ruta  UNC  se  realiza  haciendo  uso  de  la  siguiente  sintaxis: 
-  \\2001-db8-81al-bdl-l  1  ll-145a-14a-1001  ,ipv6-]iteral.net\ 
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Fig.  5,9.- Acceso  a  una  carpeta  compartida  mediante  [Pv6. 


5.1.4.-  Direcciones  Well-Known  en  IPv6 

Además  de  las  direcciones  de  Enlace  o  Vínculo  Local,  en  la  familia  de  protocolos  IPv6  hay 
una  buena  cantidad  de  direcciones  que  deben  ser  conocidas  -  al  igual  que  sucede  en  rPv4 
así  que  toca  ahora  describir  las  más  importantes  para  entender  luego  los  entornos  de  ataque: 

-  ;:/128:  Es  una  dirección  con  todos  los  bits  a  0.  Es  la  dirección  IPv6  indefinida. 

-  i:/0:  Es  la  dirección  de  red  IPv6  para  describir  la  ruta  por  defecto  en  una  tabla  de 
enrutamiento.  Es  equivalente  a  la  dirección  IPv4  0. 0.0.0. 

-  ::  1/128:  Localhost  en  IPv6.  Equivalente  a  127.0.0.1  (lPv4). 

-  fe80::/1 0:  Direcciones  de  vínculo  o  enlace  local.  No  son  enrutables  pero  generan 
una  red  local  efectiva  en  el  rango  fe80::/64.  La  parte  de  ¡iost  se  suele  calcular  a  partir 
de  la  dirección  MAC  de  la  tarjeta. 

-  fiD2::/16:  Direcciones  de  redes  [Pv6  Multicast.  Equivalentes  a  las  (224.X)  en 
redes  TPv4. 

-  fc00::/7:  Son  las  direcciones  para  redes  lPv6  privadas.  Estas  direcciones  tampoco 
son  enrutables  en  Internet  y  son  equivalentes  a  lO.X,  172.16.Xy  192,1 68. X  en  redes 
IPv4 

-  ::ffff: 0:0/96:  Direcciones  lPv4  mapeadas  en  lPv6.  Se  utilizan  para  conversiones  e 
interconexiones  de  protocolos  IPv4  e  IPv6. 
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»  64:ff9b::/96:  Direcciones  IPv6  generadas  automáticamente  a  partir  de  IPv4.  Se 
utilizan  para  cuando  sea  necesario  hacer  nuevas  direcciones  lPv6  y  se  quiera  generar 
a  partir  de  la  dirección  TPv4  de  la  máquina. 

-  2002::/! 6:  Indica  que  es  una  red  6  to  4  mapeada  y  utilizará  la  dirección  TPv4 
192,88.99.x  como  gateway  para  la  interconexión. 


Además  de  estas  direcciones,  hay  algunas  rcserv'adas  para  propósitos  especiales,  como  son 
las  siguientes: 

-  2001  ::/32:  Usado  por  el  protocolo  de  túneles  Teredo  que  permite  hacer  tunneling 
IPv6  sobre  redes  lPv4  en  internet.  Este  sistema  es  el  que  se  utiliza  a  la  hora  de 
implementar  Direct  Access  en  Windows  Server  2008  R2  y  Windows  7. 

-  2001:2::/48:  Asignado  a  Benchmat'king  Methodology  Working  Group  (BMWG) 
para  comparativas  (benchmarkíng)  en  lPv6  (similar  a  la  red  198,18,0.0/15  para 
comparativas  en  IPv4). 

-  2001:10::/28:  ORCHID  ((h^eriay  Routahíe  Crypíographic  Hash  Identifiers). 
Direcciones  IPv6  no-enrutables  usadas  para  identifícadores  criptográficos  Ifash. 

-  2001:db8::/32:  Direcciones  utilizadas  para  documentación  o  ejemplos  lPv6. 
Similar  a  las  redes  192,0.2,0/24,  198,51,100.0/24  y  203.0.1 13.0/24  en  lPv4, 


5.L5."  Precedencia  de  protocolos 

Una  de  las  preguntas  que  se  debe  realizar  cuando  tenemos  un  equipo  en  su  configuración 
por  defecto  es  la  siguiente:  “si  en  un  equipo  tiene  instalado  lPv4  e  lPv6  por  defecto,  ¿qué 
protocolo  va  a  utilizar  el  sistema  operativo?"’  En  este  apartado  de  este  capítulo  se  va  a 
intentar  responder  a  esa  pregunta  y  a  cómo  se  resuelven  las  direcciones  de  los  integrantes 
de  la  comunicación,  cuando  en  los  dos  equipos  están  configurados  los  protocolos  lPv4  c 
IPvó.En  los  entornos  actuales,  lo  más  probable  es  que  el  protocolo  iPv6  conviva  junto  con 
el  protocolo  lPv4  -  y  puede  que  incluso  algún  otro  más  -  así  que  el  sistema  operativo  deberá 
elegir  en  toda  comunicación  ente  utilizar  una  conexión  con  IPV6  y  hacerlo  con  el  más 
conocido  IPv4  según  algunas  normas  definidas  y  configuradas.  Estas  normas  se  definen 
mediante  un  algoritmo  de  precedencia  definido  en  el  RTG  3484  y  en  el  más  reciente  de 
Septiembre  de  2012  RFC  6724,  titulado  ^'Defauit  Address  Selection  for  Internet  Proiocol 
versión  6  (IPv6)’’  en  el  que  se  explica  cuáles  son  las  normas  para  elegir  IPv6  o  IPv4  en  un 
entorno  mixto. 
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El  documento  explica  dos  algoritmos  basados  en  la  dirección  de  origen  y  la  dirección 
de  destino  para  elegir  un  protocolo  u  otro.  Estos  algoritmos  tienen  en  cuenta  detalles  de 
la  configuración  completa  de  las  ocmunicaciones  de  un  sistema  infonnático,  como  la 
existencia  o  no  de  puertas  de  enlace  configuradas  en  cada  protocolo,  ya  que  podría  darse  la 
circunstancia  de  que  el  origen  fuera  una  dirección  lPv4,  el  destino  también  otra  dirección 
IPv4,  pero  esta  se  encuéntrase  en  otra  red  -y  sólameiite  existiera  configurada  una  puerta  de 
enlace  para  el  protocolo  lPv6,  por  lo  que  se  podría  elegir  un  encapsulado  de  direcciones  IPv4 
sobre  TPv6  para  poder  encaminar  el  tráfico  hasta  el  destinatario  final  de  la  comunicación. 

En  un  sistema  informático  con  Microsoft  Windows  se  puede  consultar  esta  configuración 
en  todo  momento  por  medio  del  comando  Netsh  iníerface  ípv6  show  prefix,  donde  se 
mostrará  por  pantalla  una  tabla  de  prioridades  con  valores  similares  a  la  que  se  puede  ver 
a  continuación. 


Fig,  5. 1 1  -  Tabla  de  precedencia  por  defecto  en  un  Microsoft  Windows  1 . 


86 


Ataques  en  redes  de  datos  ÍPv4  e  IPv6 


El  algoritmo  de  precedencia  da  prioridad  a  lPv6  sobre  IPv4  si  es  posible  establecer  una 
comunicación  con  este  protocolo,  pero  en  cualquier  momento  se  puede  modificar  este 
comportamiento  haciendo  uso  de  !os  siguientes  comandos  Neish. 

-  Netsh  interface  ipv6  show  prejixpolicies:  Muestra  la  tabla  local  de  políticas 

-  Netsh  imerface  ipv6  add prefbcpohcies:  Añade  nuevas  entradas  a  la  tabla 

-  Netsh  interface  ipv6  set  prejlxpolicies'.  Configura  entradas  en  la  tabla 

-  Netsh  interface  ipv6  delete  prefixpolicies:  Borra  entradas  en  la  tabla 


Ejemplo: 


-  Netsh  íníerfüce  ipvó  set  prefixpolicies  pr€jix=2001  ::/32  precedence~15  labelos 


Además,  este  comportamiento  no  interfiere  para  nada  en  la  elección  que  haya  realizado 
anteriormente  una  aplicación  o  un  usuario  de  forma  explícita,  por  lo  que  solo  es  una  regla 
de  comportamiento  para  cuando  no  se  ha  establecido  una  restricción  previa* 

A  la  hora  de  elegirse  entre  1  Pv4  e  IPv6,  tendrá  mucho  peso  la  con  figuración  de  la  red  a  la  hora 
de  buscar  un  resolver  un  nombre  de  un  host.  Por  ejemplo,  si  ei  DNS  busca  automáticamente 
el  nombre  del  equipo  añadiendo  el  sufijo  del  dominio  de  la  compañía  y  el  servidor  DNS 
de  la  compañía  solo  responde  con  lPv4  entonces  se  utilizará  IPv4  porque  no  se  ha  podido 
hacer  el  Discovery  en  IPv6. 


5.1.6.-  Descubrimiento  de  vecinos  con  Neighbor  Discovery  Protocol 


Para  descubrir  los  vecinos  de  una  red  TPv6  no  existe  el  protocolo  ARP  o  RARP,  y  todo  se 
basa  en  mensajes  ICMPvó.  El  protocolo  para  descubrimiento  de  vecinos  se  llama  Neighbor 
Discovery  Protoco!  e  impl ementa  5  tipos  de  mensajes  distintos. 
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Fig.  5J2.-  Desciíbrimicnto  de  vecinos  con  mensaje  NS  Mulíícasí  y  respuesta  iinicast  NA. 
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De  ellos,  los  equivalentes  al  protocolo  serían  los  mensajes  Neighhor  Solicitatíon  (NS), 
donde  se  pide  la  resolución  de  una  dirección  MAC  asociada  a  una  dirección  lPv6  y  Neighbor 
Advertisemení  (NA),  donde  se  contesta  con  la  dirección  liíAC de  la  dirección  !Pv6  buscada 


Lo  nomia!  es  que  estos  mensajes  sean  enviados  a  una  dirección  Multicast  y  que  a  ellos  solo 
conteste  aquel  vecino  que  tenga  configurada  la  dirección  IPv6  que  se  busca  por  la  red,  pero 
también  pueden  ser  mensajes  unicast  enviados  a  una  dirección  concreta  de  !a  red  a  la  que 
se  interroga  para  saber  si  conoce  o  no  conoce  a  dicho  vecino- 


Todas  las  direcciones  MAC  asociadas  a  sus  correspondientes  direcciones  IPv6  quedarán 
almacenadas  en  una  parte  del  sistema  operativo  que  se  conocer  como  Tabla  de  vecinos  y 
que  puede  ser  consultada  en  cualquier  momento  haciendo  uso  del  comando  Netsh  mterface 
ipvó  show  Neighbon 
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Fig-  5.13  -  Tabla  de  vecinos  en  iPv6. 


Como  se  puede  suponer,  estos  mensajes  tendrán  una  gran  importancia  en  varios  de  los 
ataques  que  se  van  a  describir  un  poco  más  adelante  en  el  protocolo  lPv6  de  tipo  D.O.S. 
(Deniel  of  Service)  y  Man  in  the  middle. 
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5.1.7*'  Resolución  de  nombres  a  direcciones  IP  en  ámbito  local 

En  el  caso  de  los  sistemas  Microsoft  Windows^  cuando  se  realiza  la  resolución  de  nombres, 
para  poder  funcionar  con  lPv4  e  TPv6  se  incluyó  el  protocolo  LLMNR  {Link-Local  Muhicast 
Ñame  Resohdion),  descrito  en  el  RFC  4795,  un  protocolo  que  utilizando  Muhicast  permite 
resolver  las  direcciones  TPv4  y/o  lPv6  asociadas  a  un  nombre  de  dominio.  Este  sistema 
permite  realizar  búsquedas  locales  o  mediante  el  uso  de  resolución  de  registros  A  y/o 
AAAA  con  un  servidor 


Fig,  5.14,-  Resolución  de  srv  por  LLMNR  usando  Kfulticmt  ]Pv6,  IPv4  y  DNS. 

utilizando  la  resolución  de  nombres  con  LLMNR,  la  búsqueda  de  direcciones  MAC  de 
vecinos  con  NDP  y  a  la  tabla  de  precedencia,  los  sistemas  Microsoft  Windows  construyen 
la  comunicación  entre  equipos  con  TPv6. 


5.1.8.-  Configuración  de  equipos  IPv6  en  la  red 

Para  configurar  el  protocolo  IPv6  de  los  equipos  de  una  red  existen  diferentes  alternativas. 
La  primera  de  ellas  sería  realizar  una  Configuración  Estática  o  manual,  en  la  que  se 
configuran  la  dirección  IPv6,  la  Puerta  de  enlace  y  los  servidores  DNS  de  forma  individual 
y  manual  -  o  mediante  un  script  -  en  cada  equipo. 

La  segunda  forma  de  configurar  es  utilizar  un  servidor  DHCPvó  para  configurar  todas  las 
propiedades  IPv6  de  los  equipos  de  un  ámbito  de  red  lPv6,  Estos  servidores  DHCPvó  están 
soportados  en  los  servidores  Windows  Server  2008,  Windows  Server  2008  R2  y  Windows 
Server  2012.  Al  igual  que  se  hacía  en  lPv4  se  pueden  configurar  dirección  IPv6,  prefijo 
de  red  -  o  máscara  o  servidores  DNS  a  utilizar,  La  tercera  fonua  de  configurar  equipos  en 
la  red  es  mediante  el  protocolo  Neighbor  Discovery  Protocol  y  los  mensajes  RS  (Router 
Solicitation),  RA  {Router  Advertisimeni)  y  Redirect,  junto  con  el  funcionamiento  SLAAC 
{Stateless  Address  Auto  Configurator)  de  los  equipos. 

La  idea  es  que  un  equipo  puede  conectarse  automáticamente  en  una  red  con  IPv6  si  conoce 
algún  router  de  conexión.  Para  ello,  el  equipo  realiza  una  petición  RS  en  busca  de  una 
puerta  de  enlace.  Todos  los  routers  de  la  red  le  contestarán  con  un  RA  dándole  a  SLAAC 
la  información  necesaria  para  que  el  equipo  se  autoconfigure  una  dirección  lPv6  que  le 
permita  tener  conectividad  a  través  del  router.  Si  hay  más  de  un  router  en  la  red,  y  el  equipo 
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elige  un  router  como  primer  salto  erróneo,  este  le  contestará  con  un  mensaje  NDP  de  tipo 
Redirect  informándole  de  cuál  es  la  mejor  ruta,  para  que  actualice  su  tabla  de  enrutamiento* 

Por  supuesto,  tanto  DHCPvó  y  SLAAC  van  a  poder  ser  utilizados  para  realizar  ataques 
D,O.S.  y  Man  ín  (he  middle  en  las  redes  IPvó,  como  veremos  más  adelante,  con  esquemas 
de  Rogue  DHCPvñ  Servers  o  Rogue  Routers. 


5.1.9.-  DNS  Autodiscovery 


Cuando  un  equipo  se  conecta  a  la  red  ÍPv6  a  través  de  una  configuración  SLAAC  existe 
el  problema  de  que  no  se  pueden  configurar  los  ser\d dores  DNS  y  todas  las  peticiones  de 
resolución  se  reducen  a  LLMNR  de  tipo  difitsión  en  busca  de  posibles  servidores  en  ía 
red  de  vínculo  local  Sin  embargo,  si  el  servidor  fuera  externo  es  necesario  contar  con  un 
servicio  de  resolución  de  nombres  DNS  en  la  red  TPv6.  Para  ello,  cuando  no  se  configura 
ningún  servidor,  los  equipos  Microsoft  Windows  buscan  automáticamente  tres  direcciones 
lPv6  establecidas  por  el  estándar  ÍPv6  DNS  Autodiscovery, 


34»  «Sii  SMÜSa  f CODS  í  2  f :Gí í  l3 
34»  614324 


351 :4®7v:S2O#6»fC0?Oí  :2 
3  S¿  4»2¿  B2á7Í»  fcüÓ:  :2 

m  myríss»rím^T 

3  54  SÓÍV$233a7  f cOOi  :2 
355  501  f cQÜ ;  í2 


f &C0 ;  O ;  O :  ffff : 
f  ecO :  O :  O  : :  2’: 


. ^ery  aam  i  ucas  p  cofB 

DNS 


Éj^d^gueQjAAAAlu^^ 

*P3*quS*y  TSBBT  TCfcas^cSSr 

89  sc^ndard  query  aaaa  lucas. com 
39  standard  query  aaaa  lucas. com 


f  eco :  O :  O  ;ff  ff :  ;1 


fec0;0:0;ffff; 
356  501.624322  fcQD:  fecOiQrQ;fff^: 


standard  query  aaaa  lucas. cgm 


Standard  query  aaaa  lucas. con ^ 
m  standard  qüjry  aaaa  lúeas. 


Fie.  5.15.-  Direcciones  lPv6  de  los  DMS' Autodiscovery. 


Si  una  empresa  no  quiere  usar  DHCPvó,  puede  configurar  un  DNS  en  una  de  esas 
direcciones  lPv6  y  junto  con  un  router  IPv6  enviando  mensajes  RApara  que  los  clientes  se 
autocon figuren,  podrá  tener  la  red  funcionando. 


5.2.-  Ataque  man  in  the  middle  de  Neighbor  Spoofing 

Como  ya  se  ha  visto  anteriormente,  para  descubrir  a  todos  los  vecinos  de  una  red  de  equipos 
con  lPv6  se  utiliza  el  protocolo  NDP  (Neighbor  Discovety  Protocol).  Este  subconjunto  de 
mensajes  ICMPvó  cuenta  con  dos  mensajes  concretos  que  convierten  la  dirección  [Pv6  a 
una  dirección  de  enlace  local  (Local-Link)  que  en  las  redes  de  datos  de  área  local  será  la 
dirección  MA  C.E1  funcionamiento  habitual  es  que  un  equipo  envíe  un  mensaje  de  Neightbor 
Solíciiatlon  NS  a  una  dirección  Multicast  cuando  vaya  a  comunicarse  con  un  equipo  y  que 
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el  que  tenga  esa  dirección  IPv6  responda  al  mensaje  Mulücast  con  un  mensaje  unicast  de 
Neighbor  Adver tisement  NA  con  su  dirección  física  AfAC.  El  receptor  del  mensaje  NA 
almacenará  en  la  tabla  de  vecinos  la  dirección  IPv6  y  la  dirección  MAC  asociada. 


Sin  embargo,  al  igual  que  con  el  protocolo  AliP  en  lPv4,  un  atacante  puede  enviar  un 
mensaje  NA  sin  haber  recibido  el  mensaje  previo  de  NS  y  hacer  que  en  la  caché  de  la  tabla 
de  vecinos  se  almacene  el  registro.  Un  ataque  de  Neighbor  Spoo/mg  para  hacer  ^ían  in  the 
middle  se  basará  por  tanto  en  enviar  un  mensaje  NA  a  los  dos  equipos  a  los  que  se  quiere 
hacer  el  ataque,  poniendo  en  ambos  ia  dirección  IPv6  del  otro,  y  la  dirección  MAC  del 
atacante. 


Fig.  5.16.-  Paquete  NA  enviado  spoofearido  la  1?\6  fe8Ü::f47c:d2ae:b534;40h2, 


63  standard  query  A  srv 


192*168.1,204  224.0,0,252  LLWWR 

feSOí  :f95c:b7c5rea34;d3ff  feSO;  :f47c:d2ae:b534 :40b2  LUñm 


102  Standard  cfoary  rfispons 
63  Standard  qu€ry  aaaa  sr 


fe5Q:  :f95c:b7c5  :ea34  :d3ff  feSO;  :f47ctd2ae:b534:4Qb2  líMHR  102  Standard  query  respons 


ü)C6Vuuouuu 


0. . .  . . . . . . .  . . .  «  Router  :  Nót  set 

.1 . . .  .  -  Solicited:  set 

..1-  . . .  ...,  -  Over  r  i  de:  set 

...0  0000  0000  0000  0000  0000  0000  OOOO  -  Reser vedi  0 
Target  Address :  feSO: :f9Sc:b7c5 rea34 ;d3ff  <feS0: :f 95c i b7c5 ; ea34 :d3ff ) 
ICWPV6  option  (Target  link-layer  address  ;  08: 00:27:3f :05 :4e> 

Typei  Target  I1nk-1 ayer  address  (23 

I  anrrrh*  1  ÍR 


ÜOJBSl 


ICHPw 


Fig.  5.17.-  Paquete  NA  enviado  spoofeando  la  1P\'6  fe8Ü::P?5c:b7c5:ea34:d3ff. 
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El  ataque  se  realiza  spoofeando  la  dirección  IPv6  de  origen  del  paquete,  para  simular  ser 
un  mensaje  que  viene  del  otro  equipo  víctima,  pero  en  ambos  casos  se  pone  la  dirección 
MAC  del  atacante,  para  conseguir  que  el  switch  de  comunicaciones  haga  llegar  todos  los 
mensajes  a  la  máquina  del  hombre  en  medio. 


5.2.1.-  Parasiteó  (The  Hacker’s  Choice) 

Una  de  las  herramientas  que  implementa  estos  ataques  es  Parasiteó,  de  The  Hacker’s  Choice 
(THC).  Esta  hen^amienta  está  incluida  en  BackTrack  y  Kali,  Por  defecto  la  herramienta 
realiza  man  in  the  míddle  entre  todos  los  equipos  IPv6  que  descubre  por  la  red,  por  lo  que 
ponerla  activa  en  una  red  de  datos  en  la  que  hay  IPv6  es  meter  un  auténtico  parásito. 

Los  pasos  para  que  funcione  con  la  configuración  por  defecto  son: 

1)  Poner  primero  una  dirección  IPv6  en  el  interfaz  de  red  de  BackTrack  que  esté  en  la 
red  en  que  se  va  a  hacer  el  ataque. 

-  ifcotifig  ethO  inetó  add  [ipv6] 

2)  Arrancar  Parasiteó 


-  Parasiteó  ethO 


ootvjbt:'-#  parasiteó  eth2  ’  ,  - 

-..-ember  to  enable  robting  (ip  fon</3rtling) ,  you  will  denigl  ¿srvice  otbe'rwise! 
Started  ICHP6  fJeighbor  Sotiticatlon  Interceptor  (Press  Control-C  to  end)  ' 
SpGOÍed  pacKet  to  feSS: : 197C:41S9;6248;4d62  óS  feSB; :8a0: Icee:25f9:b35 
Spoüfed  packet  to  fe89:  ;8G0:lcee;25f9;b85  as  feSS': ;  i97c  :4139:íi24d;4ci62 
^.poofed  packet  to  fe88: :a0Q:27f f : fe9d: bcob  as  fe89: Icee:2óf9:bg5 
Spoofed  pacKet  to  fír80^  :a00;27ff  :ft'Sc!:bc0b  as  fe38; :  197c :4139:6?43r4(362 
Spoofed  pacícetií  t;p  fe83r  :l|lC:4139:624a^4ti52  as  :Tpae:.;^aOé:27ff ;  fe9<i;bc0ta 
rpcofed  packet ''to'  fésjS;  r¿Óé  ;  Ícée:25f9;ba¿  aS  fe¿Ó:  ;aG0: 2?f f ;  feSd  ;bc0b 


Fig.  5.18.'  Activando  Parasiteó  en  Bactrack. 

3)  Configurar  el  enrutamiento 

-  sysctl  -w  net.ipv6.conf.all.for\varding=l 


í Qombt : sysctl  -w  riet.ipy&.corif  .all.forv/arding^l 
'■iet.ipv6.Gonf  .sil .  forvi'arding  =1 

ríoííiifct-;-»  - 


Fig.  5.19.-  Activación  del  ennitaTniento  en  ÍPv6. 
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4)  Activar  un  sniffer  {Wireshark)  y  analizar  los  paquetes. 


'  root^bt:  - 

n 

■  --L.  --r:.  -i- ;  -= 

:  ■  -  '  ■  ■  -  '  '■  ■t’ .  . -í  i  ^  tíce 
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■"  -:■■■  ---'I  •  :  Vi, Ti  255,  0^'  f  f  s.  Tr- ■  'avlO.-í 
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•  :  ‘'-"í  i  ;  :  i ,  V,  ■  ‘  -  Tc.j.t*'r4,.  ovi?^  r  'daj  - 

VI,  T  í;k  Cpvivr'  "2’  ,  2^  T’ '■  ' 

T:  ;  :  .  >5.  oext  •  Ív-aóír'r  v  p  ,  id 

i-i  ■  ■  :::\  ^^IíÍí^  Ok]  íisí ' (jt 

L- ;  í-  •  ^  .HpT '  p  ^  ;  1 í; ,  i  1 ; ,  ipng ‘:2  lí  ^  1 ;  :  2. .  -  f  ^  .  2 

‘iZ-  :-"2.  ■  2  V  .:25^  s!  v  Tt  ^  ^ií^ddt'í  I  .rírvó  258  5 

:.:  ■  '^>6  o-,  l  TíjíPr.^  neíOÍVOC;  SdV?  í  . 

^  ‘’-v  í  ^  .ye:  ¡.ir] 

3.:  • 

íi.Tryt"  ’7  ,  '  :  V 

■ 

Fig.  5.20.-  Tráfico  TPvó  captijrado  con  TCPDump. 

A  partir  de  ese  momento,  se  empezarán  a  enviar  mensajes  NA  para  hacer  man  in  the  middle 
en  las  direcciones  IPv6  detectadas  y  se  envenenarán  las  tablas  de  vecinos  de  todos  ellos. 
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Fig.  5.21-  Direcciones  JPv6  apuntando  todas  a  la  dirección  AL4C  del  cquipn  con  Para^iteó. 


Por  desgracia,  el  número  de  herramientas  que  analizan  los  flujos  sobre  TPv6  no  son  muchos 
aún,  y  no  contamos  con  muchos  filtros  que  recompongan  ficheros  transmitidos  o  analicen 
sesiones. 
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Sin  embargo,  en  la  versión  Deveioper  de  Wireshark  -  actualmente  1.11.2  -  que  puede  ser 
descargada  desde  la  web  del  proyecto  en  la  sección  de  en  desarrollo,  se  cuenta  con  el  plugin 
que  recompone  los  ficheros  enviados  sobre  el  protocolo  SMB  -  tanto  sobre  lPv4  como  lPv6 
-  sin  uso  de  cifrado. 


y:  ¡.vy 

1  Pacfcet  num  Hostname  Content  Type 

Bytas 

Filena  me 

i 

\VTREEtO_2049  FILE  {4096/156849)  RI  2.61%3 

0 

\d^f  a  p2.doc 

1  27a 

\\TREB0^2049  FILE  {4096/114688)  R I  3.57%] 

0 

\cífet>row.dQc 

I 

\\TREEID^2049  FILE  (65536/114688)  R  [57.14%J 

114688 

\cifebrow.doc 

42S 

\\TREeD„2049  RLE  (14336A4336)  R  fl0a00%l 

0 

\RruebaEj<ceLxls 

470 

\\TR€EID^2049  RLE  (198219/1^219)  R  [lOO  OOToJ 

198219 

\SMB-CORE.PS 

66$ 

\\TREEIO,2049  RLE  (438174/438174)  R  EIOO.00%3 

438174 

\SMS-LM1X.PS 

:  1020 

\\TREEID_2049  FILE  (268617/268617)  R  [100.00%] 

268617 

\SM&-LM20.PS 

1244 

\VTREEID_2049  FILE  (270613/270613)  R  [100.00%] 

270613 

\CIFS-Auth-Spec.ps 

1450 

\\TREB0_2049  FILÉ  (114688/114688)  R  {100.00%] 

114688 

\áfsbrow.ácc 

1557 

UTREEIO_2049  FILE  {15684 9/1 5 6849)  R  [100,00%) 

156043 

\cifÍ5rap2.dQc 

1718 

\\TRÉEID_2049  FILE  (29215S/292155)  R  [100.00%] 

292155 

\CI  FS-Secur  ity '  Conadera  tson  s.  ps 

1914 

\\TREEID_2049  FILE  (13/13)  R  [100.00%] 

0 

\Creado  desde  |v{LabXP2  .tKt 

1979 

\\TREEID_2049  FíLÉ  (3043583/4509951)  R  [67.49%]  4S099S1  \Guui!nstalac(on_7 B68.pdf  | 

^H«lp  i 

i  ^  Save  ás  :2i5ave  All  ■  ^Cancel  | 

Fig.  5.22,-  Recomposición  de  ficheros  (Tan.^milidos  sobre  SMB. 


5.2.2.-  Scapy  Project 

Otra  herramienta  que  se  puede  utilizar  para  crear  los  paquetes  necesarios  para  realizar  este 
ataque  en  la  red  lPv6  es  Scapy.  Esta  herramienta  es  un  potente  interface  interactivo  basado 
en  Python,  que  tiene  como  objetivo  fundamental  la  manipulación  de  paquetes.  Trabajado 
con  múltiples  protocolos,  permite  escaneos,  test  de  equipos,  ataques  de  red  y  cómo  no 
ataques  de  envenenamiento. 

El  siguiente  ejemplo  muestra  cómo  crear  paquetes  falseados  de  tipo  ICMPvó  que  tienen 
como  objetivo  hacer  que  un  cliente  adquiera  una  información  de  dirección  fisica  asociado 
a  una  dirección  TPv6  totalmente  falseada. 

Para  ello  a  través  de  Scapy  es  necesario  configurar  los  parámetros  que  permitirán  construir 
el  paquete  falso.  El  primer  paso  consistirá  en  introducir  los  parámetros  de  la  capa  2.  En  este 
caso  se  generará  un  paquete  dirigido  a  un  sistema  con  dirección  física  00: 00: 00:00: 00:01, 
especificando  en  el  origen  la  dirección  MAC  del  atacante. 


94 


Ataques  en  redes  de  datos  IPv4  e  lPv6 


Fig.  5.23.-  Coíi figuración  de  capa  2  con  Scapy. 


Tras  este  primer  paso  será  necesario  configurar  los  parámetros  de  la  capa  3.  En  este  ejemplo 
se  especifica  como  dirección  de  origen  la  correspondiente  a  una  de  las  víctimas  y  la  de 
destino  a  la  otra,  que  deberá  coincidir  con  la  dirección  física  especificada  anteriormente  en 
destino. 
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Fig.  5.24.-  Configuración  de  capa  3  con 


El  paqoete  ya  se  encuentra  configurado  para  ser  distribuido,  tal  y  como  se  muestra  en  la 
siguiente  imagen,  donde  se  pueden  ver  todos  los  valores  configurados  en  todos  los  campos 
del  mismo.  Ya  solo  falta  enviar  el  paquete  por  la  red,  y  esto  puede  realizarse  con  un  simple 
comando  que  ofrece  Scapy^  y  en  el  que  se  eligen  cosas  como  la  interfaz  de  red^  la  pila  de 
protocolos  o  si  se  quiere  realizar  un  loop  con  el  envío: 


Sendp(ether/ipv6/na/lla,  {face^'ethO  \  ioop=l,  mter=5) 
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Fíg.  5.25.-  Trama  NAlCMFvó  falseada. 


El  envío  de  tramas  falseadas  a  las  dos  potenciales  víctimas  implicará  en  ta  práctica  la 
realización  de  la  técnica  de  hombre  en  medio,  en  un  ataque  muy  dirigido,  tal  y  como  se  ha 
explicado  de  forma  manual  en  el  apartado  anterior  con  Parasíteó.  Para  completar  el  ataque 
totalmente  solo  será  necesario  utilizar  alguna  herramienta  tipo  snlffer  para  interceptar 
el  tráfico  emitido  entre  los  equipos  a  los  que  se  ha  realizado  el  man  in  the  mlddle.  La 
combinación  con  otras  herramientas  o  con  el  propio  Scapy\  permitirá  la  alteración  de  íos 
paquetes  para  la  implementación  de  técnicas  más  complejas  como  el  Hijacking  de  sesión  o 
un  Pass  the  Hass  en  IPv6. 

Puedes  descargar  la  herramienta  desde  la  web  de  Scapy  Project  [//^^P://www^secdev.org/^ 
projects/5ca/;y]  y  tienes  más  infonnación  en  la  presentación  que  se  hizo  en  la  pasada  Hack 
In  The  Box  2006  titulada  Scapy  and  lPv6  networking  [/f7TF://void.gr/kargig/''ipv6/iScapv- 
ÍPv6_HtTB06.pdt]. 
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5.2.3.-  Neighbor  Spoofing  con  Evil  FOCA 

Para  la  realización  de  todos  los  ataques  de  IPv6  -  además  de  algunos  en  TPv4  -  que  se  ven 
este  capítulo,  desde  Tntbrmática  64  -  y  posteriormente  Eleven  Paths  -  se  creó  la  heTramienta 
EvU  FOCA,  Una  utilidad  que  sirve  para  probar  los  diferentes  ataques  de  los  que  se  va  a 
hablar  aquí,  que  es  gratuita  y  puede  descargarse  desde  la  página  web  del  laboratorio  de 
Eleven  Paths,  donde  se  publican  todas  las  herramientas  del  mismo. 


El  primer  ataque  que  se  introdujo  en  Evil  FOCA  fue  el  que  se  ha  visto  realizado  ya  con 
Parasiteó  o  que  se  puede  realizar  con  Scapy  de  NA  Spoofing.  La  idea  es  hacer  un  ataque 
de  man  in  the  middle  en  la  red  local  con  paquetes  NA  Spooteados.  En  esta  primera  captura 
se  puede  ver  que  Evil  FOCA  ha  descubierto  dos  equipos  que  tienen  tanto  direcciones  TPv4 
como  IPv6  configurado,  pero  que  se  ha  elegido  hacer  un  ataque  man  ¿n  the  middle  sólo  en 
IPv6  utilizado  un  esquema  de  Neighhor  Spoofing  con  lCMPv6. 


Fíg.  5.25  -  Evil  FOCA  haciendo  nUtrn  con  Neighthor  spoofing. 


Se  activa  Wireshark  en  la  máquina  del  atacante  y  después,  desde  el  cliente  se  conecta  a  un 
recurso  SMB  en  el  servidor  en  el  que  se  accede  a  un  fichero  llamado  Passwordtxt  en  el  que, 
como  se  puede  ver  en  la  previsualización  está  la  contraseña  buscada. 
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Analizando  el  tráfico  capturado  en  la  máquina  atacante,  podemos  ver  que  todo  el  tráfico 
SAÍB  ha  sido  transmitido  sobre  lPv6,  por  lo  que  se  han  podido  grabar  todos  los  paquetes 
que  forman  parte  de  los  ficheros. 
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Fig.  5.28.-  Tráfico  Sm  sobre  IPv6, 


Haciendo  un  seguimiento  del  flujo  TCP  es  posible,  como  se  ve  en  la  siguiente  caphira. 
acceder  a  los  ficheros  que  se  han  transmitido. 
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Fig.  5.29  -  Ficheros  tmosmitídos  porS.líS  caplurados. 


5.3.-  Descubrimiento  de  equipos  de  la  red 

Uno  de  los  grandes  problemas  a  la  hora  de  atacar  una  red  por  lPv6  es  el  de  conocer  qué 
equipos  están  disponibles  en  la  red.  Para  ello,  la  forma  más  habitual  es  la  de  escuchar  el 
tráfico  de  la  red  en  modo  pasivo  e  ir  reconociendo  todas  las  direcciones  IPv6  que  por  allí 
circulen.  El  problema  de  este  método  es  que  al  estar  las  redes  con  estructuras  de  switching 
no  siempre  es  posible  acceder  a  todas  las  direcciones. 

Otra  de  las  aproximaciones  que  se  puede  realizar  es  escanear  el  esquema  de  direcciones 
lPv4  en  que  esté  configurado  el  equipo  del  atacante  y  obtener  la  resolución  de  nombres. 
A  partir  de  ese  momento,  con  la  resolución  de  nombres  se  puede  hacer  uso  del  protocolo 
LLMNR  para  obtener  sus  direcciones  IPv6  y  ver  cuáles  están  en  el  vínculo  local.  Como  ya 
se  ha  visto,  hacer  uso  del  protocolo  LLMNR  implica  también  hacer  consultas  al  DNS  de  la 
red  buscando  los  registros  AAAAde  todos  los  hostnames  que  se  hayan  descubierto. 

Estos  dos  esquemas  iniciales  son  los  que  utiliza  Evil  FOCA  para  saber  qué  equipos  están 
cerca  y  son  susceptibles  de  ser  atacados  por  lPv6,  pero  se  pueden  aplicar  otros  mecanismos 
para  hacer  más  efectivo  el  proceso  de  descubrimiento  de  red  en  IPv6. 
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En  busca  de  un  descubrimiento  exhaustivo  del  segmento  de  red  local  se  podría  optar  por 
usar  nmap  y  hacer  un  descubrimiento  masivo  de  todo  el  segmento  fe80::/64,  pero  sería  un 
consumo  alto  en  tiempo  y  recursos. 

Otra  aproximación  sería  la  de  intentar  averiguar  las  direcciones  IPv6  de  vínculo  local 
asignadas  a  una  dirección  MA  C teniendo  en  cuenta  que  el  estándar  original  de  las  direcciones 
IPv6  de  vínculo  local  utiliza  la  dirección  MAC  como  base  para  generar  la  parte  de  host. 

En  ese  esquema,  de  los  64  bits  asignados  al  ¡dentificador  de  Host  en  una  dirección  IPv6  de 
vínculo  local,  los  24  primeros  corresponde  con  los  24  bits  de  mayor  peso  en  la  dirección 
MAC  y  después  se  rellena  con  la  constante  FF  FE  y  luego  se  ponen  los  24  bits  de  menor  peso 
de  la  dirección  MAC. 

Sí  hay  algún  equipo  dentro  de  ia  red  que  aún  utilice  este  sistema  de  generación  de 
direcciones  de  vínculo  local  para  IPv6,  podrá  ser  descubierto  por  cualquier  escáner  de  red 
con  un  sencillo  proceso  de: 


Fig.  530.-  Generación  de  la  parte  de  Host  en  la  dirección  de  vínculo  local  en  IPv6. 


Es  decir,  se  utilizan  primero  los  24  bits  más  significativos  de  la  dirección  M4C,  después  se 
añaden  las  contantes  FF  FE,  y  por  último  se  agregan  los  24  bits  menos  significativos  de  la 
dirección  MAC  de  la  tarjeta. 

Por  ejemplo,  en  los  equipos  con  MAC  OS  X,  para  obtener  la  dirección  de  vínculo  local 
lPv6,  el  segundo  bit  menos  significativo  del  byte  más  significativo  de  la  dirección  MAC  es 
cambiado  con  un  complemento  a  uno,  así  que  si  es  1  se  pone  un  0  y  si  es  0  se  pone  un  1.  En 
este  caso,  se  ha  puesto  a  1 ,  y  el  segundo  valor  en  hexadecimal  ha  pasado  de  e4  (01 1 101 00)  a 
e6  (01 1 101 1 0).  Esto  se  puede  ver  en  la  siguiente  captura  hecha  en  un  M/IC  OS  X  Moimíaín 
Lian  1 0,8.2. 


ene:  f Ufls^e863<UP,  8R0A&CAST ,  SMART,  RUWIMG,  SIWPL£X,MULT1CAST>  nitu  1500 
ether  |e4  B?^»gTW?TO 

inet6  VeBB;  jSBcéigíif f ;  fd&B:  14B^en0  prefixlen  64  scopeld  9x4 
inet  192.168.1.41  netmask  0xffffff6B  broadeast  192. 168.1. 255 
media:  autoselect 

_ status;  active _ 


Fig.  5.31 Dirección  de  vínculo  local  en  IPv6  y  Aí4Cde  un  MAC  OS  X  10.8,2. 


En  ella  se  puede  ver  cómo  la  MA  C  de  la  tarjeta  está  dividida  por  el  medio  usando  la  contaste 
FFFE,  y  aparecen  los  64  bits  de  host  de  la  dirección  IPv6,  que  tiene  una  dirección  de 
vínculo  local  con  un  prefijo  de  64  bits. 
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Debido  a  esta  curiosidad,  es  posible  utilizar  el  protocolo  lPv4  para  hacer  un  cscaneo  de  la 
subred  utilizando  el  protocolo  ARP  y  obtener  una  serie  de  direcciones  MAC.  A  partir  de 
ellas,  utilizando  la  dirección  de  red  de  vínculo  local,  generar  direcciones  lPv6  siguiendo 
este  método,  y  probar  si  es  una  dirección  IPv6  que  está  siendo  utilizada.  Es  decir: 

-  1 )  Escanear  una  dirección  IPv4  con  ARP 

-  2)  Generar  una  lPv6  de  vínculo  local  a  partir  de  la  MAC 

-  3)  Probar  la  IPv6  generada 

Para  evitar  esta  debilidad  en  la  generación  de  direcciones  lFv6,  existe  el  RFC  4941  sobre 
Extensiones  de  Privacidad  que  propone  utilizar  direcciones  de  vínculo  local  con  parte  de 
host  totalmente  aleatorias.  Por  defecto  sólo  se  utiliza  este  método  para  las  direcciones 
autogeneradas  con  SLAAC,  y  éstas  solo  se  utilizarán  para  conectarse  con  un  router  al  que 
se  ha  conocido  por  medio  de  un  paquete  Router  Advertisement  y  no  para  conectarse  con 
un  vecino  del  mismo  segmento  que  también  tenga  la  misma  dirección  de  vínculo  local.  No 
obstante,  se  podría  cambiar  este  comportamiento  por  defecto  manipulando  los  parámetros 
de  IPvó. 

En  el  caso  de  Evíl  FOCA  también  se  incorpora  una  opción  de  descubrimiento  de  red  para 
localizar  los  equipos  que  están  haciendo  routing,  es  decir,  las  pasarelas  de  la  red  o  aquellos 
que  estén  haciendo  un  ataque  man  in  íhe  middle,  configurando  el  tráfico  a  Internet  a  través 
de  uno  de  estos  equipos  y  viendo  si  funciona. 


5.4.- Ataque  man  in  the  middle  con  SLAAC 

Como  ya  se  ha  comentado,  dentro  de  las  funcionalidades  que  se  aportan  en  la  implementación 
de  lPv6,  una  de  ellas  consiste  en  la  posibilidad  de  realizar  una  configuración  rápida  de  un 
adaptador  de  red,  donde  los  parámetros  son  proporcionados  por  un  router.  La  capacidad  de 
SLAAC  [StateLess  Address  Auto  Conjiguration)  viene  definida  nuevamente  a  través  de  la 
/ÍFC4861  y  puede  ser  utilizada  por  un  atacante  para  configurarse  como  puerta  de  enlace  en 
la  red  TPv6  y  acceder  a  todas  las  comunicaciones. 

Cuando  se  instala  un  sistema  operativo  moderno  como  Microsoft  Windows  1  o  MAC  OS  X 
Mavericks  -  por  poner  algunos  ejemplos  la  implementación  predeterminada  implica  que 
tanto  lPv4  como  IPv6,  se  encuentran  habilitados  por  defecto  y  configurados  para  obtener 
IP  y  opciones  de  red  de  fonna  automática. 
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El  objetivo  del  ataque  es  poder  hacer  un  man  in  the  middle  cuando  un  usuario  se  conecta 
a  Internet  a  un  servidor  que  no  tiene  soporte  para  IPv6  y  que  por  lo  tanto  es  necesario 
conectarse  usando  lPv4*  Hay  que  tener  en  cuenta  que  sitios  tan  populares  como 
Microsoftxom  no  tienen  soporte  para  lPv6,  pero  es  que  además  la  mayoría  de  los  equipos 
de  conexión  en  internet,  tanto  de  infraestructuras  de  redes  profesionales  como  domésticos 
tampoco  soportan  lPv6,  por  lo  que  es  necesario  que  aún  el  tráfico  por  Internet  vaya  en  TPv4 
o  con  conexiones  encapsuladas. 

Para  poder  realizar  este  ataque  a  una  conexión  IPv4  de  Internet  a  través  de  un  man  in  the 
middle  en  lPv6,  el  objetivo  dcl  atacante  será  configurar  correctamente  el  soporte  IPv6  para 
la  víctima  y  buscar  un  entorno  en  el  que  lPv4  deje  de  funcionar.  Una  vez  desconfigurado 
IPv4  y  configurado  IPv6,  será  necesario  hacer  el  cambio  de  la  red  IPv6  a  la  red  IPv4 
configurando  los  servicios  NAT64  y  DNS64  para  que  el  equipo  no  pierda  conectividad. 


Fig.  5  J2.-  Tanto  el  servicio  DNS64  como  NAT64  esUiián  corriendo  en  el  mafr  in  /he  middle. 


5.4.1.- Ataque  man  in  the  middle  SLAAC  con  Evil  FOCA 

Para  entender  el  ataque  antes  debemos  echar  un  vistazo  a  ios  registros  DNS  del  sitio  que 
se  va  a  utilizar  de  ejemplo,  www.rootedcon.es,  donde  se  puede  ver  que  no  hay  direcciones 
lPv6  asociadas  a  él.  Una  vez  se  termine  el  ataque  se  va  a  conseguir  que  el  cliente  navegue  a 
esta  web  usando  ÍPv6  en  su  red  local,  a  través  de  un  esquema  de  man  in  the  middle. 

Para  este  ataque  la  fonna  más  sencilla  de  conseguir  el  efecto  es  buscar  un  equipo  conectado 
a  Internet  por  un  router  que  solo  tenga  soporte  sólo  para  IPv4  y  que  tenga  un  servicio 
DHCPv4  para  asignar  direcciones  lPv4  a  todos  los  equipos  que  se  conectan. 
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En  este  entorno  se  debe  conseguir  que  el  servidor  DHCPv4  no  le  de  ninguna  dirección 
l?v4  ni  puerta  de  enlace  a  la  víctima  haciendo  un  ataque  Rogue  DHCPv4  o  DHCP  ACIL 
Injector  que  configure  al  equipo  víctima  con  una  dirección  IPv4  de  vínculo  local  en  TPv4 
(169.254.X.X)  y  sin  puerta  de  enlace  o  bine  haciendo  un  ataque  de  denegación  de  servicio  al 
servidor  Dl¡CPv4  para  consumir  todo  el  rango  de  direcciones  IPv4  que  tenga  para  asignar. 


|C;\>iis  laokup  ^ 

^Servidor  prtjdet erninífcdci : 
iHddreGs: 

>  í;erver  8/8,8  *8 
e  rKf  ido  i*  ppc? d<?  t  e m inado  : 

^Í^ddi'esíí ;  8  *0 ,8  ^8 

'>  set 

>  tnju* roQt edcon -es 

Sero  idor:  tjoogle  publ  íc  dfts-a ,  le  ,con 

ñddresr/:  8, 8. 8, 8 

Nonbi^e  -  ui;i^,rootedcon  -  es 

t>  - 


Fig.  5.33.-  v^^’w.roootedcon.es  no  tiene  direcciones  IPv6. 


UnKnovín 


cfODífle  pitblic  dns  a  . «con 


El  ataque  para  dejar  al  servidor  Di/C/*  sin  direcciones  IPv4  aasignar  a  veces  no  es  necesario, 
ya  que  en  muchas  redes  públicas  la  mala  configuración  del  tiempo  de  asignación  de  cada 
dirección  lPv4  los  equipos  tienen  las  direcciones  muchas  horas  asignadas  y  los  nuevos  no 
consiguen  ninguna. 

Sin  embargo,  en  Metasploit  viene  el  módulo  de  DNS  Exhaustion  Attack  que  continua 
realizando  peticiones  DllCP  request  con  diferentes  direcciones  MAC  hasta  que  el  servüdor 
deja  de  responder. 


msf  >  use  auxiliary/diginin ja/dhcp_exhaustion/e3£hai2st 
mgf  auxiliaryí  exhauñt )  >  show  opt;ions 

Module  options : 


Ñame 

Current  Setting 

Required 

Description 

riLTEH 

no 

The  filter  string  for  capturing  traffic 

INTEHFACÉ 

no 

The  ñame  of  the  interface 

SNAPLEN 

65535 

yes 

The  number  of  bytea  to  capttire 

TiWEOÜ'T 

10 

yes 

Timeout  waiting  for  server  response 

Fig.  5.34  -  Módulo  de  DNS  Exhaustion  Attack  en  Metaspioil 
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Una  vez  que  se  ha  conseguido  esto,  el  equipo  de  la  víctima  terminará  con  una  dirección  de 
vínculo  local  tanto  en  la  pila  IPv4  con  en  La  pila  IPv6,  por  lo  que  estarán  los  dos  protocolos 
en  igualdad  de  condiciones. 


lug.  5.35.-  Equipo  vícLiina  con  direcciones  lPv4  e  IPvñ  de  vínculo  local. 


Para  conseguir  que  el  equipo  tenga  IPv6  funcionando  sólo  es  necesario  que  el  cliente 
tenga  una  puerta  de  enlace  que  apunte  a  la  dirección  lPv6  del  atacante,  en  este  caso  con 
Evil  FOCA.  Para  ello,  con  solo  enviar  un  paquete  SLÁÁC  se  consigue  que  la  víctima  se 
ponga  dirección  lPv6  con  conectividad  con  Evil  FOCA  y  la  puerta  de  enlace  apuntando  a 
la  máquina  del  atacante. 

Para  realizarlo  lo  primero  hay  que  encontrar  el  equipo  víctima  entre  la  lista  de  equipos  que 
han  sido  descubiertos  en  la  red,  por  lo  que  la  fase  de  descubrimiento  de  equipos  con  IPv6 
en  la  red  es  tan  importante  ~  y  como  hemos  visto  no  siempre  tan  fácil  de  realizar  debido  al 
gran  rango  de  direcciones  que  habría  que  escanear 

Después,  se  selecciona  como  objetivo  del  ataque  que  se  quiere  realizar  en  el  panel  de  la 
derecha,  que  en  este  caso  es  el  ataque  de  SLAAC  {StateLess  Adress  Auto-Configuraüon). 
En  ese  panel  es  necesario  configurar  el  prefijo  de  red  necesario  para  que  la  víctima  se 
cofifígure  la  dirección  lPv6,  que  supuestamente  le  dará  salida  a  Internet  por  IPv6, 

Ese  prefijo  es  el  que  supuestamente  el  router  de  conexión  tiene  configurado,  y  hará  que 
el  equipo  lo  encuentre  cuando  quiera  salir  hacia  otra  red  fuera  dcl  segmento  local  en  el 
que  está  configurado  el  equipo.  Toda  esta  configuración  se  hace  dentro  de  las  opciones  de 
ataques  en  MITM  IPv6  que  vienen  en  la  herramienta  Evil  FOCA. 
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MITM  tPvS 


WITM  IPv4 


DoSÍPv& 


0¿S  H^4  "T  HMdng 


^  Neighbor  ddv'ortimiiQnl  f  SLAAC 


Targets  FWbcflPvS): 
Taryets 


fc00::0 


Macktyi 


Versión 

1FV6 

IPv6 

IPv€ 

IPv6 

IPv€ 


IFV6 

tPv6 

tPvS 

tPv6 

IFV£ 

IFSfS 

IPvS 

IPv€ 


OOsncd 


O0 


Fig.  5.36.-  Selección  de  víctima  del  ataque  SLAAC. 


Una  vez  configurada  la  víctima  y  el  prefijo  de  red  lFv6  a  utilizar  ^  es  conveniente  no  utilizar 
un  prefijo  de  red  IPv6  que  esté  configurado  en  la  red  actualmente,  solo  hay  que  lanzar 
el  ataque  de  tbrma  definitiva  haciendo  clic  en  el  botón  Start  En  ese  preciso  momento  la 
víctima  de  este  ataque  recibirá  un  paquete  ICMPvó  de  tipo  RA  (Router  Advertisment)  para 
que  el  protocolo  SLAAC  del  equipo  decida  configurarse  una  dirección  IPv6  dentro  de  ese 
prefijo  de  red  para  tener  conectivídad  con  el  router. 

En  este  ataque  en  concreto  no  es  necesario  configurar  el  servidor  DNS  por  ÍPv6  haciendo 
uso  de  un  servicio  DHCPvñ,  ya  que  por  defecto,  en  el  momento  en  que  una  máquina 
tiene  puerta  de  enlace  para  salir  de  la  red  local,  podrá  buscar  los  servidores  DNSv6  en  las 
direcciones  establecidas  por  el  estándar  para  los  servidores  DjV5Autodiscovery,  tal  y  como 
se  puede  ver  en  la  imagen  siguiente  donde  aparecen  configurados  ya. 
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Fig,  5.37.-  Dirección  JPv6  conñguradu  por  SLAAC,  Gateway  IPv6  en  dirección  de  atacante  y  servidores  DNSvó  Antodiscovciy 

configurados. 

Por  supuesto,  como  todas  las  direcciones  de  los  servidores  Autodiscovery  están  fuera 
de  la  red  local  de  la  víctima,  todas  las  peticiones  de  resolución  sobre  ellos  pasarán  por 
la  puerta  de  enlace,  es  decir,  el  equipo  en  el  que  está  corriendo  £v¡/  FOCA.  El  aiacante 
se  ocupará  de  que  todo  el  tráfico  de  red  sea  correctamente  procesado  para  que  tenga 
conectividad  -  incluido  el  ¡cono  que  pone  tVtudows  para  representar  que  un  equipo  tiene 
conexión  a  Internet 

A  partir  de  ese  momento,  la  víctima  tiene  configurada  toda  la  conexión  lPv6  en  su  sistema, 
y  bastará  con  abrir  el  navegador  de  Internety  pedir  la  dirección  URL  a  la  que  se  quiera 
conectar,  para  que  Fvíl  FOCA  haga  el  resto  del  trabajo  y  consiga  que  le  llegue  la  página 
web  hasta  el  navegador* 

Como  se  había  visto  en  la  Fig  5.33,  el  hostname  vvww.rootedcon*es  no  tiene  asociada 
ninguna  dirección  lPv6,  y  en  la  captura  que  se  puede  ver  en  la  captura  de  la  Fig  5.38 
que  se  encuentra  en  la  página  siguiente,  en  ella  se  muestra  como  el  equipo  víctima  en 
su  configuración  del  protocolo  IPv4  solo  cuenta  con  una  dirección  IPv4  de  vínculo  local 
169.254*233*2  que  además  no  cuenta  con  ninguna  configuración  de  puerta  de  enlace  en  la 
red  IPv4  o  DNSv4. 
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|Ífl(  Smtboío  ctet  f^sterní 


■^'saJíüiíí: 


:  ñtíajtt iido Ir  rtt*  r ’irt'it nr i*  Irít.L-l<R> 


Suí  í  jn  ftí:  |inc  :  J  xcíi  iKíi'ft  la  c«nexi>n.  .  : 

ífííi  . . :  Aclaiít  ado  ir  rtó  r ’irt'it  nr  i*  Irít.L-l<R> 

m 

Direiícrírin  fisiíia . 0lf  -ít0-27  'Í4  9í  -^1 

DHCl^  Ivabíliti^do  -  . .  ,  _  .  :  no 

Cúnf  inri  autunátita  Ivahilitada  .  .  ,  :  :íÍ 

Díi'cccjnn  íPuf»  í  f  JlnVíi  2B9fj2  ¡rVñfrCFai'tfeirido  > 

Uínpulo:  dirección  iPyí>  local.  .  .  t  f  ofiílt  iíidS9  2  ]  c?2  :t{9ít2  :f  ?flb/í  llíPi'cf  éi?itío> 


Dirección  lPv4,  .  .  .  ,  ^  .  . 

Máscara  dií  culirifd  . 

Puerta  dfí  enlnE-o  |jr«dfíCerí^Ífiaíía 
IftíD  DíídPvb  .......... 

DUÍD  do  clicritM.  DHCpob.  ^  . 

bF  (15  79 

í  Serwidores  DMíí.  . . . 


r  169.254.233.2CPi'efei‘idci> 

;  ZíiS- .25£i  .  25&_0 
;  fésB:  :7c27':¿5ae:fcJj5V:922d%íJl 
:  2aS405lSJ 

:  00  m  00  01  10  IV  Ri:  \i2  m  00-27 


Ni:tíJlO£  íobro  ICP/tP. 


.  .  ,  :  ree0:0í0:f fft  : 
fec0r0:0:fiff I :2^1 
fec0:0:0:ffff  :  í3líl 
_  .  .  :  habilitado 


1  .JRootedCON 

. - 

^  wv  rootedcon.es 

'  ^  SI '  íSwffíf 

P  #  D- 

Sobre  Rooted  CON 

Noticias  Congreso  Registro 

RootedLábs 

1 

Contacta  H 

:  h 

»!  m  m 

Fig.  5.38  -  Navegando  a  Rootedcon.es  sin  soporte  para  ÍPv4. 


En  el  navegador  se  puede  ver  por  el  contrario  que  la  navegación  a  la  web  w^^Tv.rootedcon. 
es  está  funcionando  perfectamente  desde  el  navegador  Mozilla  Firefox,  lo  que  quiere  decir 
que  el  cliente  -  la  víctima  -  está  pudiendo  utilizar  IPv6  en  la  red  local  para  alcanzar  un 
servidor  en  Inetre  que  está  funcionando  solo  por  IPv4.  Todo  el  trabajo  de  conversión  entre 
las  redes  lPv4  e  lPv6  está  siendo  realizado  por  el  equipo  que  actúa  como  hombre  en  medio 
utilizando  Evil  FOCA. 

En  este  entorno  Evil  FOCA  está  interceptando  todas  las  peticiones  de  resolución  de  nombres 
que  se  envi  en  al  serxidor  DNSv6  y  que  pasen  por  su  máquina,  por  io  que  no  es  necesario 
hacer  nada  especial  extra  cuando  ya  se  ha  conseguido  por  medio  del  ñincionamiento  del 
ataque  SLAAC  que  las  peticiones  pasen  por  el  equipo  del  atacante  al  ser  éste  la  puerta  de 
enlace. 

Vaya  la  petición  de  resolución  al  servidor  DNSv6  a  un  sistema  de  Internet,  a  un  equipo 
de  la  red  configurado  por  DHCFvó  -  como  veremos  más  adelante  -  o  a  las  direcciones  de 
AWAutodiscoveiy,  Evil  FOCA  va  a  responder  siempre  con  una  dirección  ÍPvó  a  cualquier 
petición  que  se  haga  desde  la  máquina  de  la  víctima.  Por  ello,  cuando  desde  el  equipo  se 
hace  un  Ping  a  \Mvtv\roo tedcon.es,  lo  que  se  obtiene  es  una  dirección  IPv6  que  contestará 
Evil  FOCA. 
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; :  MJ se  rs \t( Ke r >  ipc íin f  i  cf  ya  1 1 
Conf  Í0tUMO  ióit  TP  de  Uirídoifa 


HfMnhpo  de  boGt*  *  ..  -  -  .  .  -  ,  :  victina 

Sufijo  DNÍi  principal 

Tipo  de  líodo-  ni.xto 

Prtrut  anieuco  ÍP  habilitado  *  .  «  -  no 

Proxsí  WlNS  habilitíido  no 


í  daptadoa-'  de  EtiiDrnet  Conexión  de  árna  loc:alí 


Sufijo  DNS  eí;p0cífico  para  ía  etmexión.  .  : 

Dése  r  ipc  ion  . * . :  fidaptador  de  escr  ¿torio  liitel<fí> 

:  RD/1000  MT 

Dirección  física,  . . í  0íf-í40  27-'9d-*?l-Vl 

DliCP  habilitado  _  .  -  ,  .  .  .  .  .  .  -  -  .  =  tu> 

■;<  Dirección  í  Pu6  f  c00t  :lc?2  :tt9B2:f7ah<Pref  fírido>  S 

í  Ijínculo;  direuciüti  t£\.6  local-  :  -  :  f  eB0 : :  6db9  :  lc72  =  tí9S2  U78í>Xi  í  <fre  f  eridoy 


$  Dirección  lPo4.  .  . . :  lb9 ,2Í>4 .233 .2<  Preferido  >  é 

í  rtascara  de  fAibred . :  2SS  ,2h& .0  f 

f  Pufirt*!  de  enlace  prede  te  minada . =  f  e6íl :  -  7c2?  ^ebae  :f)bS7 : 922d^^1  l  § 

Duíp  de  Client^  ¿HCPge  *  !  :  00--RÍ -  00 -01  1? -0P-82-08  i10-'27 

ISéroidores  DNS,  f  ec0:15:0:  f  fff  :  :l*^t  * 

■;  fec0:0:8:ffff :  :2:ít 

i  ffiC0:0:B:f  fff  ^  :3'yl  ^ 


§ 


C íNlíf.e rsNiiser >pin0  vxhí- rootedeon  .es 


!íac  iendo  piny  a  umj .  roo  tedeen  .  es  Ife4  :  :  ff  f  f  ;l>009  SeSa  1  cofi  32  bytes  de  datos- 

he s  pue s l  a  de  s de  fi  4 :  :  f  í  t  f  :  b00?  '  eG  a  :  t  i  enpo  -J  ns 

ííce puesta  desde  84^  f  f  f  :  b00V  :eGaí  tienpo<Ín 

Respuesta  dosdie  64: : f  f  f  f  :  b009  : eSa :  tieíipo  3r»s 

Respuesta  desde  64  :  :f  f  f  f  ^  b009  :eGa:  tienpo  -2í>s 


r  s  i  ad  í s  t  i  c  as  de  piny  para  G  4  :  :  F  f  f  f  :  bí1íi9  :  e  6  a : 

Paí|uctes :  enuiados  -  4,  recibidos  ~  4,  perdidos  -  0 
C05<  per d idos 

I  iemnííS  ¿rproxii^iados  de  ida  g  oiielt  ti  en  ti  i  Hí^e^undos : 

h  iíttMri  -  ■  0.t>'  n;L':i  -  Ih  i  :  .  flcrFia  *'  li^ig  _ 


Fig.  5.39.-  wwwTOotedcon.es  asociado  a  luia  dirección  lFv6. 


5.4.2.-  NAT64  (NetWork  Address  Transalation  6  to  4) 


Si  se  analiza  una  captura  de  tráñeo  de  red  con  la  herramienta  Wireshark  en  la  máquina  en 
la  que  se  encuentra  corriendo  Evil  FOCA,  veremos  cómo  el  proceso  que  se  hace  para  que 
funcione  este  ataque  es  el  siguiente: 


file  |jÉ(  ÍBw  Sin  £:*ptwií  ^alBttei  Tdtplipi^  looü  ¡rtanab  i|rip 

■t  M  K  ft  «  &  n  íl  í8  a  i  í’s  'f  ♦  n  á;  1  ¡@}S  a  €l  «l  Q.i  K  Rt  íf  » 

Rifar:  dra  ]^'Eüpi«teM..-  Obx  ‘AplíJy'  ‘5«v« 


Fig.  5.40  -  Proceso  de  resolución  de  D.VSde  www.rootedcoti.cs. 
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-  Primero  la  víctima  envia  a  una  dirección  de  DNS  Autodiscoveiy  la  petición  de 
resolver  el  registro  AAAA  de  wr\'vt'.rootedcon,es, 

'  La  máquina  de  Evil  FOCA  hace  una  petición  DNS  de  tipo  A  para  resolver  www. 
rootedcon.es  a  Internet  usando  lPv4. 

-  El  servidor  DNSv4  de  Internet  responde  con  la  dirección  IPv4  de  www.rootedcon. 
es. 

-  Evil  FOCA  genera  una  dirección  TPv6  a  partir  de  la  dirección  IPv4  que  es  la  que 
entregará  a  la  máquina  de  la  víctima  para  que  haga  el  resto  de  peticiones. 

Una  vez  que  la  máquina  de  la  víctima  tiene  la  dirección  LPv6  asociada  a  www.rootedcon. 
es,  la  petición  HTTP  que  hará  el  navegador  será  por  ÍPv6.  Casi  todos  los  navegadores 
modernos  vienen  preparados  por  defecto  para  trabajar  con  IPv6  y  el  principal  problema 
siempre  suele  ser  el  router  de  conexión  a  Internet,  que  no  suele  tener  soporte  para  este  tipo 
de  redes  o  los  servidores  web  en  si. 


Fig.  5,41 Configuración  por  defecto  de  resolución  de  registros  AAAA  en  Aíoiiíiú  Firefox, 

Dentro  de  las  excepciones  de  navegadores  modernos  que  dan  soporte  a  IPv6  en  las 
conexiones  hay  que  citar  a  Google  Ckrome^  ya  que  en  él  viene  desactivado  por  defecto. 
Este  es  un  comportamiento  cuanto  menos  curioso,  más  cuando  es  posible  localizar  las 
direcciones  !Pv6  de  casi  todos  los  servicios  de  la  compañía  Google  en  Internet. 

Chemas-HacBook-Pro:^  Chem3$  nslookup 

>  set  type=AAAA 

>  WWW, google.com 

Server:  172,16.11,247 

Address :  172, 16. 11- 247#53 

Non--authoritative  answer: 

WWW- google.  cotn  has  AAAA  dddress  2a00;1456:4g0B:864: :  1013 

Fig.  5.42.‘  Dirección  lPv6  del  servidor  de  Google. com. 


Se  puede  ver  cómo  Google Youtubexom,  y  el  resto  de  grandes  servicios  de  Internet 
ofertan  sus  servicios  también  desde  Intemel,  pero  sin  embargo  Google  Chrome  no  hace 
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USO  de  IPv6  por  defecto  y  debe  ser  activado  manualmente.  Para  probar  si  el  soporte  para 
conexiones  a  sitios  usando  lPv6  en  el  navegador  de  Internet  que  se  está  utilizando  funciona, 
se  puede  invocar  una  URL  por  el  protocolo  HTTP  haciendo  uso  de  IPv6,  Esto  se  puede 
hacer  de  la  siguiente  íbnna,  donde  la  dirección  [Pv6  del  sitio  va  entre  corchetes: 

-  Wr7P;//[2001:db8:81al:bdl:ll]l:145a:14a:1001]/ 


Hay  que  tener  presente  que  para  que  funcione  una  conexión  entre  el  navegador  cliente  y  el 
servidor  wch  por  ÍPv6,  toda  ¡a  electrónica  de  red  que  interconecta  los  dos  nodos  debe  tener 
soporte  para  lPv6,  algo  que  no  siempre  sucede. 


r 


Q  chfOfne//nct-mtemaJs/^^  x 


^  ^  C  i  D  chrome://net-íntemdJs/^dns 


Capture 
Expoft 
Import  1 1 
Proxy 
Events 


I  r«solv«r 


;  s  ♦  Vtew  Rending  jopkupg 
i  ?!'  ♦  Default  address  familyi  IPV4  (IPv6  disabled)  [TEn^ 


Timelíne  j  4 
DNS  I  É  DNS  Conflguration 


Fig,  5A3.-  Google  Chf orne  Viene  con  lPv6  desactivado  por  delecto. 


En  este  caso  el  entorno  de  ataque  es  dentro  de  un  mismo  segmento  de  red,  por  lo  que  la 
electrónica  de  red  no  es  un  obstáculo,  y  sólo  necesitaremos  que  sea  posible  hacer  uso  de 
IPv6  en  el  navegador,  así  que  Google  Chrome  no  es  un  objetivo  válido  para  este  ataque. 


Una  vez  que  se  consigue  que  todos  los  hostname  en  Internet  tengan  asociada  una  dirección 
IPv6  “  generada  por  Evil  FOCA  que  hace  uso  del  servicio  DNS64  para  generar  las 
direcciones  -  el  resto  es  trabajo  de  escuchar  la  petición  lPv6  desde  la  máquina  de  la  víctima, 
solicitar  la  petición  IPv4  a  la  dirección  del  hostname  en  Tntemet,  escuchar  la  respuesta  que 
llega  encapsulada  en  lPv4  y  entregarla  a  la  víctima  sobre  IPv6, 


Es  decir,  Evil  FOCA  hará  una  implcmentación  del  servicio  NAT64  para  convertirse  en  un 
enrutador  de  tráfico  lPv6  hacia  una  red  IPv4.  En  la  imagen  siguiente  se  puede  ver  cómo  la 
víctima  hace  la  petición  por  lPv6  y  cómo  £'v/7  FOCA  la  reenvía  por  la  red  ÍPv4. 
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f  ig.  5.44.-  SoJicitud  HTTP  pasando  por  el  servicio  NAT64. 


Una  de  las  características  que  tienen  los  equipos  MS  Windows  es  que  muestran  en  la  barra 
de  tareas  un  icono  muy  reconocible  con  eí  estado  de  la  conexión  red  para  que  el  usuario  sepa 
si  tiene  conexión  solo  a  la  red  de  area  local,  si  el  equipo  tiene  conexión  a  Internet  o  si  por 
el  contrario  no  cuenta  con  ninguna  conexión  de  red.  Este  estado,  se  comprueba  mediante  la 
generación  de  una  serie  de  consultas  a  servidores  DNS  a  servidores  de  Microsoft  para  saber 
si  es  posible  llegar  a  ellos  o  no. 

Aunque  a  lo  largo  de  las  versiones  de  Windows  Vista  -  donde  se  introdujo  por  primera 
vez  -  a  Windows  8.1  esto  ha  cambiado  un  poco,  la  filosofía  es  exactamente  la  misma.  La 
herramienta  de  Evi!  FOCA  delecta  todas  estas  peticiones,  y  las  responde  como  espera  el 
ser\  icio  que  detecta  la  conexión  a  Internet,  para  que  en  la  máquina  de  la  víctima  aparezca 
el  icono  sin  que  la  víctima  pueda  deterctar  ningún  mensaje  de  alerta,  indicándole  que  tiene 
conexión  a  Internet,  como  debe  sen 
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Fig.  5  45  -  Detección  de  consultas  DI\’S  para  saber  si  hay  conexión  a  Internet. 
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5.4.3.-  Ataque  man  in  the  middle  SLAAC  con  Radvd  &  NATPD 

En  un  entorno  Linux  es  posible  utilizar  una  serie  de  herramientas  para  conseguir  un  entorno 
de  explotación  similar.  Para  construir  el  ataque  es  necesario  inicialmente  montar  un  sistema 
que  se  encargará  de  los  encaminamientos  falsos. 


Dicho  sistema  contará  con  dos  adaptadores  de  red,  uno  inleiTio  con  direccionamiento  para 
conectarse  con  la  víctima  tPv6  y  otro  con  soporte  de  tPy4  para  la  conexión  externa  hacia 
Internet.  La  siguiente  imagen  muestra  la  configuración  de  las  tarjetas  de  red  en  el  equipo 
del  atacante. 


-  ff  ircíin‘  ;g 

tho  Link  encap  ¡Eth-írnít  HN-ad-ir  08;00:27:F9:60;C3 

addr  ;  192, 168. 1.10  Bcaít ;  192. 168, 1 , 2SF  Mask  :  256-.  2SS.  255. f 
Ír.#'T6  addr;  tísSO:  ;  aOO;  27fT  ;  9;60c3.'f,4  Sccp*i;Link 

UP  BROADCí.ST  KUNNIN5  MULTICAST  (•TTU:1500  M-3tric:l 
RX  packrtsiü  errors:0  iroppífdiO  overruns:0  fraffisiO 
TX  packíts ■’246  *rrors:0  droppfrdiO  ov-rriiní.íO  carri-^nO 
collision-; :  0  t ;  IGOO 

RX  byt<rs:0  (0.0  1)  TX  bytís ;  76781  (74.9  Kl  >  ' 

-thl  Lirik  í'íicap  :  Ethernet  K^'addr  08:G0:27;4D:  73:  74 

iriet6  .addr;  f  é80:  :  aOO;  27ff  :  fe4d  :  7:-(74.- 64  'io:-pe :  Lltik 
meto  Síddr:  2001:  rl  'O  S<Mpe:Gl':'b.jl 
UP  BRQADCAST  RUNf-lIMO  HULTIC.AST-  ^^^ü;1500  Metri.::l 
R.X  pa  k*t  f:583  érrors:ü  dropped:0  overrune ; 0  franiéiO 
TX  p.íi:ket';:4  eTr;)r5:0  •lrir!pped;G  overrun?  .0  camerrO 
■';olliíi-:'n'fr:0  tiqi-iei-ielrn ;  1000 

R>:  bytéS:45Gll  (43.9  Kb;  '  tvt-rJrk.kO  (T-kO-.O  b) 

Lirik  --nc  áp  lU'Cal  Lo  :pb,ii:k 

inet  ad'Jr  •  1 2“ ,  o .  o,  1  ITAik  ;  255.  0.0.0 

ifietó  .íddi';  l;  1/128  ScopeiHost 

I.IP  L0ÜFB.ÍCK  RLINfilHG  Í-ÍTU;  16430  Metri!:! 

PX  p.i)'.keti:74  errorsrO  drcppediO  civerrunf,;0  fr.HtnetO 
TX  packetí. :  ?4  errcrG  :  0  dr’^ppediO  overrun-s ;  0  cárrier  ;0 
vlllsicri:-; :  O  txqU“i.)eleri ;  0 
RX  byteí.;4020  0. 9  Kb  i  T:'.  byte-^:4020  (?.9  Kbj 


Fíg.  5.46.-  Configuración  de 3  atacante  para  hacer  un  ataque  SLAAC. 


En  ía  imagen  aiilerior  es  importante  darse  cuenta  de  la  dirección  de  vínculo  local 
(Scope.  Link)  que  será  la  utilizada  para  atender  las  solicitudes  de  descubrimiento  de  router 
en  la  red.  Puesto  que  el  sistema  se  va  a  encargar  de  los  encaminamientos  será  necesario 
habilitar  e^  forwarding  de  los  paquetes. 
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Ataques  en  redes  de  datos  IPv4  e  IPv6 


La  luiicionalidad  de  atender  las  solicitudes  y  proporcionar  los  valores  de  configuración 
adecuados  puede  establecerse  a  través  del  paquete  Radvd.  A  continuación  se  muestra  el 
fichero  de  configuración  de  la  aplicación  para  definir  los  parámetros  del  ataque  que  se 
quiere  realizar. 

En  él  hay  que  configurar  cosas  que  ya  se  han  explicado  con  anterioridad  como  el  prefijo  de 
la  red  en  la  que  se  va  a  configurar  el  falso  router  y  dar  el  serv  icio  de  encaminamiento  hacia 
Internet  -  u  otras  redes  para  que  la  víctima  se  configure  de  forma  automática  haciendo  uso 
de  SLAAC  una  dirección  de  ese  segmento. 

Como  se  ha  explicado  ya,  desde  un  paquete  SLAAC  no  se  puede  configurar  las  direcciones 
de  los  servidores  DNS  por  lo  que  será  necesario  interceptar  las  peticiones  que  se  emitan  a 
los  servidores  pre-establecidos  por  el  estándar  de  D^V^SAutodiscovery  o  bien,  en  el  supuesto 
caso  de  que  se  quisieran  enviar  las  peticiones  a  un  servidor  DNS  concreto,  configurar  un 
servidor  Rogue  DHCPvá  para  poner  los  valores  adecuados. 


interface  e 

thl 
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Sen 

dAdvert  on: 
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Oth 

erConfigFlag  on; 

Min 

[Rtr 

Advlnterval  3; 

Max 

RtfAdvInterval  lOj 

pre 

/ 

fix 

2001  s  :  m 

\ 

AdvÜnLinIc  orv. 

AdvAutonoiBous  or»; 

>í 

AdvRouterAddr  on; 

Fíg.  5.47.-  Fichero  de  con  figuración  del  programa  Radvd. cowí. 


Una  vez  que  ha  sido  puesto  en  marcha  el  servicio  Radvd,  los  clientes  que  tienen  activa  la 
configuración  predeterminada  del  protocolo  lPv6,  recibirán  una  respuesta  a  sus  peticiones 
de  enrutamientos  en  TPv6  que  realicen  mediante  el  protocolo  iCMPv6  usando  paquetes 
RS  (Router  Soliticitation).  Además,  el  servicio  también  genera  periódicamente  mensajes 
ÍCMPvó  de  tipo  RA  {Router  Advertisement)  para  dejar  claro  que  hay  un  nuevo  router  lPv6 
conectado  a  la  red  para  dar  servicio 

La  siguiente  imagen  muestra  un  equipo  con  la  información  correspondiente  a  los  valores 
previos  de  configuración  de  red  iPv6.  En  este  caso  en  concreto  el  equipo  tiene  una  dirección 
IPv4  privada  en  el  segmento  192.168.1.X  y  no  se  ha  configurado  ninguna  puerta  de  enlace 
que  le  pennita  tener  conexión  a  Internet  -  podría  ser  un  equipo  que  navegue  por  un  proxy 
local,  por  ejemplo. 
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Conf  IP  de  yindovíí* 


l'ldapt ador  dé  Ether-net  CoTiexión  de  local* 

Sufijo  DNS  específico  pai'a  la  conexión.  -  ; 

Uínculo:  dirección  í  PoE  local.  .  .  :  f  «80 :  : t d44  : i745 -6Beb: h72a>íll 

Dxv'ección  ÍPvl.  -  ,  ,  .  ,  .  .  .  .  .  .  -  .  ^  192.168.1-2 

Háscaca  de  subred  *  .  -  . . -  .  .  :  25S -2S5 .255 .  B 

Puéi'ta  de  enlacé  predeterf^inada  .  .  ,  ,  .  “  192.168.1.1 

ndaptador  de  tuf^cT  isatáp-<58F'íS65l -47ED“4C06—9BAC”CCE418F78D4D> : 

Estada  de  los  medías.  medios  de&conect ados 

Sufijo  DKS  específico  para  la  conexión,  .  : 

údapíador  de  túnel  Conexión  de  ó  re  a  local**  4; 

Estado  de  los  medios.  medios  désconect ados 

Sufijo  DNS  específico  para  la  conexión.  .  : 


Fig.  S4íi.-  Configuración  dcl  diente  antes  dd  ataque  SLAAC  Radvd. 

En  la  siguiente  imagen  se  puede  ver  la  configuración  del  mismo  equipo  justo  después  de 
arrancar  el  servicio  Radvd  en  el  equipo  del  atacante.  En  la  configuración  se  aprecia  como 
el  direccionamiento  de  la  víctima  ha  sufrido  un  cambio  drástico  y  ahora  hay  una  nueva 
dirección  lPv6  y  una  nueva  puerta  de  enlace  en  la  red  IPv6  configuradas  por  el  serv'icio 
SLAAC  del  cliente  y  que  tiene  un  prefijo  de  red  marcado  por  el  paquete  RA/RS  que  haya 
llegado  a  é1  vía  ICMPvó. 


hfjfif  iíforAC  i  «JO  EP  f3e  ‘..Windows 


i'uíaptador  dé  Ethernet  Conexión  de  órea  local - 
Sufijo  DNS  específico  para  la  conexión,  .  : 

Dirección  I Po6  -  .  .  .  .  .  :  2BB1 : : 1 d44 í 4745 :65eb: b72a 

Di  rece  id  rs  !  Pv6  temporal. . :  20B1 :  :ae  :e4l>e  -  7ca3  :81af 

Uinciilo*  dirección  I Po6  local.  .  .  :  f e8B: : ld44:4?4S :65eb"h72a^l t 
Dirección  !Pv4.  .  -  .  .  .  .  .  ,  ,  -  .  .  ,  ;  192,168,1.2 

Has  cara  iie  suhred  . . 255  .255 . 2SS  .  B 

Puerta  de  enlace  predeterminada  f  :a00:27f  F  : ft:4d:7374xll 

192.168 .1  .i 

Adaptador  de  túne  1  isatap.C58F:i5651- 47ÉD  4Cí16-9BñC-CCll4l8F?8D4D> : 

Estado  de  los  medios .  .  .  .  .  .  .  -  .  .  .  "  medios  desconec tados 

Sufijo  DNS  específico  para  la  conexión.  .  * 

Adaptador  de  túnel  Conexión  de  área  local»  4: 

Estado  de  los  medios.  ....  nedíos  desconectados 

Sufijo  DNS  especifico  para  la  conexión,  .  t 


Fig.  5.49,-  Configuración  del  cliente  después  del  ataque  51L4/ÍC  con  Radvd. 


Para  que  el  ataque  sea  efectivo  será  necesario  que  el  louter  falso  pueda  realizar  la  translación 
de  direcciones  JPv4  e  IP\6,  es  decir,  que  tenga  configurado  el  servicio  NAT64.  Esto  se 
puede  realizar  a  través  del  servicio  naptd  existente  para  distribuciones  Linux. 
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Para  ponerlo  a  funcionar  de  forma  cómoda  y  rápida  existe  un  cómodo  asistente  que  va 
guiando  los  pasos  sobre  cada  uno  de  los  detalles  necesarios  para  la  correcta  configuración 
del  servicio,  llamado  naptd-confmaker.  La  siguiente  imagen  muestra  la  función  de 
configuración  de  dicha  aplicación. 


iin«x-2w'fs ; .  (?tí.  «  ríáf'td'Confmakí'r 

IFv4/IPíO=  NAPT  Cjnfiijiir>stlOií  Hak-er 
{-:)  2005  by  Luka?z  Toitii'-ki  -í-tOfficififiO'.  pV> 

Do  you  want  to  vreat-  a  nt-w  ■oi'ifl'Aur.stion?  ÍV/nl 
y  “ 

Dv  y¿‘U  *ant  IPv4  fr<)Si  tU^  .•.utsi-.lí.-  tí?  be  autoiriíitiCdV 

u'írd  as  part  of  tbe  NAT  poC'i?  ÍY/fi] 

Dc  y-u  wartt  to  conflagra  additi-maT  addr^ss  as  part  ot  your  MAT  pool?  tw 

Ni 

n 

1,0  you  want  to  croato  a  pool  ot  publi-:  IPv4  aíldríss*':?  that  wiU  allow  iik; 
omiti'i  cíírin*'.  tions  te  b<í  'ivriaíHiCiillv  ftapp-íd  t-?  appropr  iat-í  rPvO  ad<ír«ís*e3  ? 
¡y -Ni 


Fig.  5,50.-  Configuración  de  ta  aplicación  naptd. 

Una  vez  completado  el  asistente  y  lanzada  la  aplicación  habrá  que  realizar  las 
configuraciones  oportunas  en  los  servicios  de  firewal/  iptables  e  ipótables  para  permitir 
b  translación  y  enrutamiento  de  direcciones  IPv6  e  lPv4,  a  la  vez  que  se  descarten  los 
paquetes  innecesarios.  Las  siguientes  son  las  reglas  que  deben  configurarse  para  un  entorno 
como  el  del  ejemplo  que  se  ha  puesto  aquí* 

-  ipótables  -A  OUTPUT  -p  icmpv6  — icmpv6-type  1  -j  DROP 

-  ipótables  -A  FORWARD  -d  200 1  :fPff : :  -j  DROP 

-  iptables  -A  INPUT  -i  lo  -j  ACCEPT 

-  iptables  -A  INPUT  -m  State  -State  ESTABLISHED  --J  ACCEPT 

-  iptables  ^A  INPUT  -m  State  —State  NEW  -p  tep  -m  tep  — dport  22  -j  ACCEPT 

-  iptables  -A  IN  PUT  -j  DROP 

El  último  paso  consistirá  en  implementar  un  proxy  DNS  por  ejemplo  con  totd,  para  la 
resolución  de  los  registros  host  solicitados  por  las  víctimas.  Ya  estará  todo  dispuesto  para 
que  las  peticiones  pasen  a  través  del  atacante.  Esto  permitirá  por  lo  tanto  la  reconducción 
del  tráfico  de  las  víctimas,  produciendo  el  robo  o  la  modificación  del  tráfico  en  tránsito. 
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5.4.4.-  Ataque  man  in  the  middle  SLAAC  con  SuddenSix 

La  anterior  lista  de  acciones  a  realizar  manual  mente  son  un  trabajo  bastante  pesado  pese  a 
la  existencia  de  asistentes  que  guíen  la  configuración  de  parte  del  proceso,  por  eso  mucha 
gente  prefiere  utilizar  herramientas  con  interfaces  de  usuario  más  amigables,  como  Evil 
FOCA  o  el  script  de  configuración  de  todo  el  ataque  que  se  presentó  en  la  edición  Defcon 
21  del  año  2013,  llamado  SuddenSix  y  que  está  disponible  en  su  repositorio  de  código  en 
/í7’7’P5://github.com/Neohapsis/ó'wcWeí75íx 

Dicho  script  configura  el  ataque  SLAAC  descrito  anteriormente  configurando  también  los 
paquetes  de  software  necesarios  para  el  proceso,  como  son  sipcalc,  tayga,  Radvd,  wide- 
DHCPvó-server  y  hind9  en  un  sistema  informático  que  tenga  Ubuntu  12.04  LTS  o  Kali 
Linux  1 .0.x,  aunque  probablemente  pueda  ser  adaptado  a  otras  plataformas  fácilmente  y 
además  ellos  se  encarguen  de  ir  tcsteándolo. 

Para  que  funcione  este  ataque  con  estas  herramientas  se  debe  ejecutar  el  scripí,  llamado 
SuddenSix.&h,  como  usuario  rooí  y  el  asistente  preguntará  por  el  interfaz  de  red  por  el  que 
se  quiere  realizar  el  ataque,  además  del  rango  de  direcciones  IPv4  a  las  que  se  quiere  atacar. 
El  resto  será  visualizar  el  tráfico  interceptado  utilizando  un  analizador  de  tráfico  de  red 
como  por  ejemplo  Wireshark. 


5.5.-  WebProxy  Autodiscovery  en  IPv4/lPv6 

Con  el  objeto  de  seguir  creciendo  y  convertir  la  herramienta  en  una  suite  de  ataques  de 
red  en  lPv4  e  TPv6,  Evll  FOCA  ha  continuado  añadiendo  ataques  a  las  características  que 
oferta  a  sus  usuarios.  La  principal  novedad  de  la  versión  de  Evil  FOCA  que  se  presentó 
en  la  edición  Defcon  21  del  año  2013  fue  la  implementación  del  ataque  de  red  basado  en 
hacer  un  man  in  the  middle  a  través  del  servicio  Web  Proxy  Auto-Discovery  tanto  en  los 
protocolos  lPv4  como  en  IPv6. 

Los  navegadores  de  Internet  por  defecto^  vienen  configurados  para  buscar  al  Servidor 
Proxy  que  les  dé  acceso  a  inlemet  por  medio  de  otro  servicio  que  se  conoce  como  Web 
Prox}'  Auto-üiscovery.  Este  servicio  de  descubrimiento  se  basa  en  el  uso  de  un  registro  en 
el  servidor  weiEknown  creado  en  el  servidor  DNS  y  que  es  llamado  WPAD. 

Esta  opción  está  activada  en  todos  los  navegadores  por  defecto,  tal  y  como  se  puede  ver  en 
las  opciones  de  Internet  Explorer  que  se  muestran  en  la  imagen  que  aparece  en  la  página 
siguiente. 
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Fig.  5.5 1 ,-  Opción  de  buscar  a utOTTiátic ámenle  la  configuración  de  la  red. 


Por  siipiicslo,  la  recomendación  de  seguridad  es  quitar  esta  característica  si  estáis  en  una 
red  que  no  es  vuestra,  y  si  es  una  red  gestionada  por  vosotros,  se  debería  aplicar  alguna 
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Este  registro  WPAD  es  buscado  automáticamente  por  toda  la  red  mediante  el  protocolo 
LLMNR,  tal  y  como  se  puede  ver  en  la  siguiente  imagen,  tanto  por  IPv4  como  por  [Pv6, 
pero  buscando  un  registro  tipo  A,  es  decir  la  dirección  lPv4  donde  se  debe  conectar  el 
navegador  para  descubrir  al  servidor  Web  Proxy^. 


La  búsqueda  del  registro  WPAD  se  hace  por  Muiticast,  y  en  nuestro  entorno,  Evil  FOCA 
captura  la  petición  que  va  con  destinatario  a  Midticast  IPv6  cuando  el  ataque  sea  a  una 
dirección  IPv6  de  la  red  o  la  petición  Multicasí  IPv4  cuando  el  ataque  se  haga  a  una  víctima 
en  la  red  lPv4,  No  hay  que  olvidar  que  Evil  FOCA  puede  hacer  este  ataque  tanto  en  red 
IPv4  como  en  red  IPv6,  Una  vez  interceptada  contestará  con  la  dirección  TP  del  atacante, 
en  este  caso,  como  el  ataque  se  realiza  en  la  red  lPv6,  contesta  con  una  dirección  IPv6 
asociada  a  un  registro  de  tipo  AAAA  pasando  con  la  respuesta  de  una  petición  de  tipo  A  a 
una  respuesta  tipo  AAAA. 
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Fig.  5.53.-  ¿Lvil  FOCA  tonkylii  con  un  registro  A^\AA. 


Al  cliente  parece  que  esto  le  deja  un  tanto  preocupado,  así  que  realiza  una  confirmación, 
buscando  el  registro  WPAD  por  LLMNR,  pero  esta  vez  preguntando  por  su  valor  AAAA,  asi 
que  no  te  extrañes  si  ves  varias  peticiones  de  este  tipo  en  tu  analizador  de  paquetes  de  red. 
Evil  FOCA  confirma  que  sí,  que  éste  es  el  servidor  al  que  debe  conectarse  para  localizar 
el  Web  Proxy  Auto-Discovery  de  la  red  y  está  en  una  dirección  TPv6  y  el  ya  el  navegador 
pasará  al  siguiente  paso. 

Como  se  puede  ver  en  la  imagen,  la  dirección  iPv6  que  se  usa  es  una  dirección  de  vínculo 
local  TPv6,  por  lo  que  no  es  necesario  hacer  un  ataque  SLAAC  previamente  para  configurar 
una  puerta  de  enlace  por  defecto  en  la  red  TPv6,  haciendo  que  el  ataque  fiincione  en  muchos 
más  entornos  de  red. 
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Una  vez  que  el  cliente  descubre  la  dirección  IPv6  del  registro  WPAD  ya  sabe  dónde  está  el 
ser\idor  Web  Proxy  Aiíto-rJíscovery.  Luego  el  cliente  se  conectará  a  éste  para  conseguir  la 
información  del  servidor  Web  Proxy  de  la  red,  que  no  tiene  porqué  ser  el  mismo. 


Es  decir,  el  serv  idor  Web  Proxy  Anto-Díscovery  es  un  servidor  web  donde  se  almacena 
un  fichero  de  configuración  que  le  dice  al  cliente  web  dónde  se  encuentra  el  servidor  Web 
Proxy. 
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Fig.  5.54.-  Solicitud  al  sen  idor  WPAD  del  fichero  de  configuración  PFP4D.FAC. 


Este  fichero  de  configuración  se  llama  WPAD.?AC  y  es  solicitado  por  el  cliente,  para  que 
Evil  FOCA  se  lo  entregue  con  la  información  del  lugar  donde  está  levantado  ese  ser\ddor 
Web  Proxy.  Su  formato  es  muy  sencillo,  ya  que  se  trata  de  un  fichero  en  formato  de  texto 
plano  que  tiene  la  información  que  puede  verse  en  el  siguiente  paquete  de  red. 
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Fig.  5.55  -  Contenido  de  IÍT!4D,PAC  ctitregado  por¿\í7  FOCA  con  información  del  Web  P’roxy. 
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Hay  que  tener  en  cuenta  que  si  el  cliente  utiliza  Google  Chrome^  este  ataque  solo  funcionará 
con  el  protocolo  de  red  lPv4  ya  que  IPv6  viene  desactivado  por  detecto,  como  se  ha  visto. 


Realizar  en  Evil  FOCA  este  ataque  es  tan  sencillo  como  arrastrar  el  equipo  al  panel  del 
ataque  WPAD  en  ÍPv6  -*  o  en  IPv4  hacer  clic  en  Start  y  Evil  FOCA  se  encargará  de 
interceptar  la  petición  del  registro  WPAD  del  cliente,  servirle  vía  web  el  fichero  WPAD.VhC 
y  hacer  de  servidor  Web  Proxy  HTTP. 
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Fíg.  5-56.-  El  aloque  WPAD  en  lPv6  con  Evil  FOCA. 


Una  vez  acabada  esta  fase,  la  víctima  ya  podrá  navegar  por  Internet  sin  notar  nada  especial, 
pero  lo  estará  haciendo  a  través  de  un  servidor  Web  Proxy  configurado  en  la  red  lPv6  que 
hará  de  man  in  the  middle  y  podrá  interceptar  todo  el  tráfico  de  red. 


Como  se  ha  dicho  antes  al  inicio  de  este  apartado,  el  ataque  también  está  disponible  para 
la  red  lPv4,  por  lo  que  por  seguridad  los  administradores  de  red  deberían  quitar  esta 
configuración  de  los  navegadores  de  [ntemel  y  monitorizar  todo  el  tráfico  de  red  con 
equipos  ÍDS  para  descubrir  quién  está  realizando  peticiones  o  respuestas  a  este  protocolo 
de  Web  Proxy  Auto  Discovery 
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5.6.-  Conexiones  HTTP-s  en  ataques  mitm  en  la  red  IPv6 

Una  vez  que  se  está  en  medio,  se  tiene  acceso  al  tráfico  que  se  está  enviando  desde  el 
cliente,  y  si  se  tiene  acceso  a  él,  existe  la  posibilidad  de  poder  interceptarlo  y  manipularlo, 
que  es  lo  que  hacen  herramientas  como  Caui^  SSLSirip,  SSLSniff,  Ettercap  en  Kali  o  la  Evíl 
FOCA. 

Según  la  herramienta  para  atacar  la  red  que  utilices,  el  comportamiento  será  uno  u  otro 
cuando  hay  que  lidiar  con  conexiones  HTTPs.  En  el  caso  de  Caín,  la  herramienta  hace  una 
copia  del  certificado  digital  original  para  enviarle  al  cliente  un  Fake-CA  como  se  ha  visto 
en  capítulos  anteriores. 

Algunas  herramientas  no  validan  que  el  certificado  cumpla  que  esté  emitido  para  ese  sitio 
en  concreto,  que  esté  caducado  o  que  esté  emitido  por  una  entidad  certificadora  válida  en  la 
que  se  confía.  Con  el  resto  de  ellas,  o  bien  no  funciona  la  conexión,  o  se  obtiene  una  alerta 
de  seguridad.  Si  el  usuario  acepta  ese  certificado,  a  partir  de  ese  momento  estará  enviando 
los  datos  cifrados  al  atacante,  que  los  descifrará,  leerá,  manipulará  y  los  volverá  a  enviar  al 
servidor  cifrados  con  una  conexión  HTTP-s  hecha,  esta  vez  sí,  con  el  certificado  original 
del  servidor  web.  Actualmente  Evíl  FOCA  no  hace  uso  de  esta  técnica,  así  que  si  quieres 
hacer  esto  deberás  hacerlo  manualmente. 

En  el  caso  de  SSLSniJf^  lo  que  se  hace  es  algo  similar,  pero  aprovechándose  de  un  BUG 
en  los  clientes  que  no  verifican  las  BasicConstralns  del  certificado  que  reciben.  La  gracia 
es  que  se  utiliza  un  cerlifícado  auténtico  pero  que  no  tiene  validez  para  crear  nuevos 
certificados.  Es  decir,  supongamos  que  el  atacante  se  saca  un  certificado  digital  para  un 
servidor  web  llamado  miserver.com  en  Verisign.  La  cadena  de  confianza  es  correcta,  y  no 
genera  ninguna  alerta  de  seguridad.  El  ataque  se  basa  en  usar  el  certificado  de  mfA’¿í/wr.com 
para  crear  certificados  digitales  falsos  para  sitios  como  www.Face¿ot;A.com  pero  finnado 
por  miserver.com.  Si  el  cliente  tiene  el  BUG  de  BasicConstrains  y  no  comprueba  que  el 
certificado  de  míA’^rví?rxom  no  tiene  autoridad  para  crear  certificados,  podría  tomar  el  falso 
certificado  de  Facehook.com  como  bueno.  Esto  le  ha  pasado  a  casi  todos  los  navegadores, 
y  al  propio  iOS  de  iPhone  no  hace  mucho. 

5.6.I.-  El  Stripping  de  HTTPs:  Bridging  HTTPs(TPv4)-HTTP(IPv6) 

En  el  caso  de  herramientas  como  SSLSmjf  o  Evíl  FOCA,  el  ataque  se  basa  en  hacer  que 
la  víctima  navegue  a  través  del  atacante  solo  con  HTTP  y  será  el  atacante  el  que  navegue 
con  HTTPs  cuando  se  conecten  al  servidor  real  En  el  caso  de  que  el  servidor  haga  un  re- 
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direct  a  HTTPs,  como  sería  por  ejemplo  cuando  el  cliente  pida  HTTP://wy^r\s\Googie\Qom 
y  el  servidor  le  intente  llevar  a  HTTPs://wwm/. Google.com,  será  el  atacante  el  que  hará  la 
redirección,  manteniendo  al  cliente  siempre  en  HTTP. 


tinpi/Awwwiacñbook.  oDm 


Redfrect  HTTP-s 


tTttps;//www.faicetxx3k,com 


Página  de  Logln 

< - ' 


Fig.  5.57.-  El  Bridgmg  HTTFs-HTTP  con  un  redirecl  de  por  medio. 


Una  vez  que  se  obtenga  la  página  de  resultados,  es  importante  que  las  cookies  de  sesión 
-  que  vendrán  marcadas  con  el  flag  secute  para  que  no  limcionen  sobre  HTTP  -  sean 
gestionadas  por  el  atacante.  Para  ello  se  puede  generar  una  cookie  falsa  que  se  envía  al 
cliente  sin  dicho  flag,  permitiendo  que  él  navegue,  y  que  el  servidor  no  note  que  ha  habido 
una  manipulación  de  cookie. 


htips  ://vvww.facebook.corn 
POST  user/pass 


C 


<; 


Logtn  OK 
Ckiokío  Secure 


Fíg.  5.58.-  La  capUtra  dé  las  credenciales  vía  HTTP  en  el  equipo  que  corre  la  Ev¡í  FOCA. 
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Esto  no  es  necesario  siempre.  Muchos  servidores  que  hacen  el  envío  de  un  mensaje  de 
redirect  a  HTTPs,  siguen  escuchando  por  HTTP,  así  que  aunque  pidan  que  todo  se  le  envíe 
por  HTTPs  se  puede  seguir  enviando  la  información  de  login  por  HTTP  y  permiten  la 
autenticación. 


En  el  ejemplo  siguiente  se  puede  ver  cómo  la  víctima  se  ha  conectado  a  www.Goog/e.com 
que  ha  pedido  el  redirect  a  HTTPs.Uwwfi.Google.coTa  pero  Evil  FOCA  ha  filtrado  esa 
conexión  y  además  ha  quitado  los  enlaces  HTTPs  de  toda  la  web,  haciendo  que  al  login  de 
Gmail  se  acceda  vía  HTTP,  lo  que  permitiría  robar  el  usuario  y  la  contraseña  en  texto  plano 
si  la  víctima  no  se  da  cuenta  de  que  no  está  en  una  conexión  segura. 


Fig.  5.59.-  PágÍTiíi  www.Goog/exom  bajo  HTTP  y  con  slripped  links. 


Para  conseguir  más  peticiones  de  inicio  desde  el  cliente  con  HTTP,  Evil  FOCA  filtra 
también  los  resultados  de  búsqueda  que  ofrece  Google,  es  decir,  que  si  la  víctima  se 
conecta  a  Google  a  través  de  una  conexión  atacada  por  Evil  FOCA  poniendo  en  la  barra  de 
navegación  HTTPJÍwwv,'.Googie.com,  cuando  el  servidor  dexoielva  un  redirect  a  HTTPs'.H 
vtww.Google. com,  Evil  FOCA  lo  interceptará,  hará  la  navegación  a  HTTPs  y  le  entregará  la 
página  de  búsqueda  al  cliente  bajo  HTTP.  Es  decir,  hace  un  Bridging HTTPs-HTTP  a  www. 
Goügle.covn.  Toda  la  lista  de  resultados  que  aparecerán  serán  enlaces  HTTP  para  garantizar 
que  Evil  FOCA  pueda  seguir  accediendo  a  todo  el  tráfico  intermedio. 


Después,  cuando  el  usuario  busque  en  Google  algo  como  Facebook,  todos  los  resultados 
que  vengan  apuntando  a  HTTPs  serán  sustituidos  por  HTTP  y  los  redirect  JavaScript  serán 
eliminados  también,  para  que  el  engaño  sea  completo. 
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En  esta  imagen  se  puede  ver  cómo  la  página  web  de  Facebook  será  entregada  vía  HTTP 
después  de  que  la  víctima  haya  buscado  la  web  de  Facebook  en  Coogle. 


Fig.  5.60  -  EvH  ['OCA  haciendo  BridgmgHTTP{\?\eyiiTTPs(yV\A)  a  www.Gofjg/e.com  y  link  strippinga  ios  resultados  de 

la  búsqueda  de  l-aeobüok 

Si  la  víctima  de  este  ataque  envía  su  usuario  y  contraseña  de  Facebook  en  una  conexión 
controlada  por  Evil  FOCA  tal  y  cómo  se  ve  aquí,  quedará  comprometida  al  ser  enviada  en 
texto  claro. 

Siempre  que  se  está  en  un  esquema  de  man  in  the  middle  hay  poco  que  hacer  salvo  cifrar 
todo  el  tráfico  de  red  contra  un  punto  de  conexión  seguro,  haciendo  uso  por  ejemplo  de  un 
servicio  de  Red  Privada  Virtual  VPN  {Virtuai Prívate Network)  haciendo  uso  de  protocolos 
de  cifrado  como  L2TP  o  SSTP  con  Certifícate  Pinning  -  que  PPTP  es  susceptible  de  ataques 
de  man  ín  the  middle  y  se  puede  crackear  por  diccionario  o  atacando  MS-Chap’V2  con 
brute- forcé  tras  la  última  reducción  de  complejidad  publicada  a  finales  del  año  201 1  - ,  y  si 
no  es  posible  mejor  que  no  se  navegue  nunca. 

Además  de  lo  dicho  ya,  hacer  uso  de  un  plug-in  que  obligue  a  navegar  siempre  vía 
conexiones  HTTPs,  el  uso  de  Certifícate  Pinning  en  aplicaciones  instaladas  en  e!  equipo 
o  de  los  sitios  web  visitados  habitualmente  desde  el  navegador  de  Internet,  para  evitar  así 
sufrir  una  vulnerabilidad  con  un  BUG  de  BasicConsírains  en  el  futuro  o  el  ataque  con  la 
ayuda  de  un  entidad  certificadora  intermedia  maliciosa,  además  de  intentar  no  entrar  a 
los  sitios  haciendo  clics  en  ningún  lugar  -  ni  los  resultados  de  Coogle  como  hemos  visto 
-  o  confiando  en  los  redireets  a  páginas  web  HTTPs^  ayudará  en  gran  medida  a  mitigar  y 
detectar  este  tipos  de  ataques. 
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5.7.-  Montaje  de  un  servidor  Rogue  DHCPv6 

Además  de  los  ataques  de  Man  in  the  middle  descritos  anteriormente  de  Envenenamiento 
de  la  tabla  caché  de  vecinos,  del  uso  del  ataque  SLAAC  o  del  esquema  de  IVeh  Proxy  Auto- 
Discoveiy  existen  otras  formas  de  atacar  una  red  IPv6  que  hay  que  tener  en  cuenta. 

La  primera  de  ellas  es  bastante  evidente,  y  consiste  en  montar  un  servidor  DCHPvó  (Dynamic 
Host  Configuration  Protocol)  en  una  red  en  la  que  no  haya  control  de  la  aparición  de 
servidores  Rogue  DCHP  para  lPv6,  que  puede  ser  algo  mucho  más  común  que  lo  deseado. 
Para  hacerlo,  es  tan  fácil  como  utilizar  cualquier  servidor  DHCP  en  Linux  o  Windows  y 
configurarlo  en  función  del  entorno. 


5.7.1.-  Montaje  servidor  DHCPv6  en  Windows  Server 

Para  instalar  un  servidor  DHCPvS  en  Windows  Server  2008  es  tan  sencillo  como  irse  a  las 
opciones  de  Roles  de  Servidor  y  añadir  el  rol  de  servidor  DHCP. 


Fig.  5.6  3  -  Añadir  rol  de  Servidor  DlíCP  en  IVindows  Ser\'cr  200S. 
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Una  vez  elegido,  habrá  que  configurar  las  opciones  básicas  del  ser\'icio,  y  en  este  caso 
se  necesita  configurar  que  se  va  a  hacer  uso  de  configuración  de  direcciones  IP  en  modo 
Statefull. 

Como  ya  se  ha  visto  en  el  ataque  SLAAC,  el  modo  Stateless  permite  que  sean  los  routers 
de  conexión  los  que  configuren  a  los  equipos,  mientras  que  con  el  modo  Statefull,  los 
servidores  DHCPvó  configurarán  de  manera  más  permanente  todas  las  direcciones  que  se 
asignen  a  ios  clientes,  estableciendo  un  periodo  de  vida  para  cada  una  de  las  concesiones 
que  realicen. 

En  este  caso,  se  debe  seleccionar  hacer  uso  del  modo  Statefull  para  que  se  configuren 
las  direcciones  IPv6  de  los  clientes  desde  el  servidor  DHCPvó  junto  con  el  resto  de  las 
propiedades  que  se  pueden  asignar  a  las  conexiones  de  red. 


Fig,  .S  ,62.-  Configuración  de  mudo  Statcfúíl  en  el  serv  idor  DCHPv6, 


Una  vez  terminada  esta  fase  del  proceso,  el  siguiente  paso  es  configurar  un  ámbito  de 
asignación  de  direcciones  IPv6  en  el  que  se  definirán  las  distintas  propiedades  de  red  a 
estableces  en  los  clientes.  Para  ello  hay  que  abrir  la  herramienta  de  administración  del 
servidor  DHCP  y  seleccionar  la  opción  de  Nuevo  Ámbito  (New  Scope]  en  el  nodo  IPv6  del 
servidor. 
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Fig,  5,63,'  Configuración  de  un  nuevo  ámbilo  T?v6, 

Seleccionando  el  nodo  TPv6  y  haciendo  clic  con  el  botón  derecho  aparece  el  menú  contextual 
con  la  opción  de  New  Scope.  T ras  hacer  clic  en  ese  elemento  del  menú,  aparecerá  el  asistente 
de  creación  de  un  nuevo  ámbito. 

En  las  opciones  de  creación  del  ámbito  IPv6  sólo  hay  que  configurar  las  direcciones  que 
van  a  ser  asignadas,  las  direcciones  IP  que  van  a  ser  excluidas  y  el  tiempo  que  se  va  a 
asignar  cada  dirección  IPv6  a  cada  uno  de  los  clientes  que  las  reeiban. 


Fig,  5,64.-  Direcciones  lPv6  que  van  a  ser  asignadas  en  d  ámbito. 
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Fig.  5,65  -  Direct: iones  lPv6  dénlro  del  ámbito  que  no  van  a  ser  entregaíias. 


Desde  el  punta  de  vista  de  un  atacante^  la  asignación  de  tiempos  debería  realizarse  igual. 
No  importa  si  la  dirección  lPv6  que  ha  solicitado  el  cliente  es  temporal  o  no  temporal,  se 
deberá  configurar  el  tiempo  que  el  atacante  estime  que  va  a  ser  necesario  para  realizarlo  con 
éxito.  No  olvidemos  que  si  el  tiempo  teiTnina,  lo  único  que  sucederá  es  que  se  producirá  un 
proceso  de  renovación,  por  lo  que  no  es  crítico. 


Fig,  5,66.-  Configuración  de  tiempos. 
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Una  vez  terminado  de  configurar  esta  parte,  el  ámbito  estará  creado  y  listo  para  empezar 
a  entregar  direcciones  IPv6  por  la  red  a  todo  equipo  que  envíe  una  petición  de  DHCP 
Requestt  por  la  red 


Fig.  5.67--  Activación  de  ámbito  JPv6  recién  creado. 

Cuando  el  ámbito  está  creado,  se  podrá  configurar  el  volumen  de  opciones  que  se  quieren 
configurar.  En  la  herramienta  de  administración  del  ser\ádor  DHCPvñ^  dentro  del  ámbito 
creado,  aparecen  como  Opciones  del  Ámbito. 


Fig.  5.68.-  Opciones  de  ÁTnbilo  configuradas. 
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Estas  opciones,  al  igual  que  en  el  servicio  DHCP  lPv4^  pemiiten  configurar  servidores 
NlSv6,  5/Pv6,  DNSv6^  etcétera,  con  lo  que  el  atacante  podría  realizar  cualquier  ataque  Man 
in  the  middle  o  Phishing  a  cualquiera  de  las  víctimas  que  hubieran  sido  configuradas  por 
este  servidor  Rogue  DHCPvó. 

Estas  opciones  también  pueden  ser  configuradas  a  nivel  de  servidor,  y  afectarían  a  todos  los 
ámbitos  que  estuvieran  configurados  en  el  equipo  con  el  rol  de  DHCP,  tal  y  como  se  puede 
ver  en  la  siguiente  imagen  en  las  que  además  se  ven  también  los  códigos  de  cada  una  de  las 
características  configurables.. 


□  90022  de  dHíCdcne*  IPVE  ite 

SI  90023  Osí-a  de  ífaeccwnes  IPV5  de  eervidaiw  ONS  de  non^íros  w 
O  00924  dé  búáhOMedé  de  dpminí^ 

□  00027  Usté  de  ÍPVE  de  wrrtdonw  NIS 

□  90028  Ü9íe  de  direccioow  IPWdb  eewkxee  N!S* 

□  00029  Lista  de  dotnros  NIS 

□  00030  Ü8te  de  nombm  de  dominto  de  e^vidciei  HIS-*- 

□  0003t  Üete  de  drecwjoee  IPVSde  swvtío-w  SNTP 


Oataenlry'  - . 

Ümm  -1  -ftrh-a  ■  ■ 

£jew  irT™  sovess. 


Server  OptkiRS 


Fign  5.69.-  Opciones  de  configuración  de  clientes  IPv6. 


Como  se  ha  visto  anteriormente  en  este  mismo  capitulo,  si  en  ía  red  ya  hay  un  servidor  con 
este  mismo  rol  que  está  asignando  direcciones  lPv4  a  los  clientes  por  medio  del  protocolo 
DHCPv4  al  que  se  quisiera  anular,  se  podría  utilizar  la  herramienta  que  viene  dentro  del 
framewok  de  explotación  de  vulnerabilidades  Metasploíi^  llamada  DHCP  Exhaustion^  que 
se  encargará  de  que  el  servidor  DCHP  de  la  organización  deje  de  atender  a  las  necesidades  de 
confíguraevión  de  los  clientes  de  la  red  al  realizar  un  ataque  de  fuerza  bruta  con  peticiones 
falsas  para  acabar  con  todo  el  conjunto  de  direcciones  del  ámbito  que  tenga  configurado. 
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5.7,2,-  Montaje  del  servidor  Rogue  DHCPvó  con  Evü  FOCA 

En  Evil  FOCA  se  añadió  también  la  posibilidad  de  configurar  los  clientes  de  la  red  con 
un  fake  DHCPvó.  Estas  opciones  en  la  implementación  que  se  ha  realizado  dentro  de 
Evil  FOCA  distan  mucho  de  tener  todas  las  posibilidades  que  ofrece  el  tener  montado  un 
ser\4dor  completo  de  DHCF  en  la  red  lPv6,  pero  para  un  ataque  rápido  o  combinado  con 
otros  es  más  que  suficiente. 


Como  se  puede  ver,  de  fonna  sencilla  es  posible  configurar  qué  valor  se  quiere  asignar  al 
senidor  DNS  de  la  configuración  lPv6  para  los  equipos  seleccionados  de  una  red,  a  los  que 
además  se  les  configurará  una  dirección  IPv6  de  un  rango  pre-establecido  y  que  funcionará 
de  forma  similar  a  un  ámbito. 


o  Progrgrn  ^  CofifigurAiofi  ^ 


«  172  mil  244 
[^  9  001560010945 
m  172.1S.11  24E 
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»  1^444 

3-  099DS71AE3eOf^RO-HW1í 
i  i  w  172  .1611240 

'  M  faSO.  id  1f4jc1  TOkíSS'^.l  6 
&  9  C46413CS2AFC 
'  m  172:16.112S1 
Roüt» 

CaD3AM7SflDf 

I  -m  fe80rcad3iB3?:fw7tbdf 

1  m  17216.112S2 

DQM1268ME7D 

i  4»  («aO  4«70 

;  m  17216  11.264 

B  9  {ffiM2£X:Da54 
m  1721611216 
a  172.1611263 
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■Hnift  LCDjmv 
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4|uÜn9«»'4fidjDH$  San^vr 
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Fig.  5,70.-  Configuración  de  un  Fake  DHCPvó  cotí  EvíÍ  FOCA^ 


En  Evil  FOCA  también  existe  la  opción  de  crear  un  servidor  falso  de  DHCP  para  lPv4,  pero 
hay  que  tener  en  cuenta  que  mientras  que  el  protocolo  DHCF  para  la  familiar  TPv4  si  puede 
configurar  la  puerta  de  enlace  las  opciones  de  la  tarjeta  de  red,  en  el  protocolo  lPv6  esto  no 
es  de  esta  forma,  ya  que  las  puertas  de  enlace  se  configuran  de  forma  dinámica  mediante  el 
uso  del  protocolo  SLAAC. 


Al  final,  el  objetivo  de  Evil  FOCA  es  poder  tener  todas  tas  herramientas  en  la  suite,  y  por 
eso  también  se  han  añadido  ataques  de  Dental  qf  Service  en  lPv4  o  lPv6,  de  las  que  vamos 
a  hablar  en  las  partes  siguiente  de  este  capítulo.  La  idea  es  que  Evil  FOCA  permita  analizar 
las  conexiones  y  los  ataques  lPv4  e  IPv6  a  pentesters,  auditores  y  estudiantes. 
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5.8.-  Otros  Ataques  y  Herramientas  para  IPv6 

Si  se  quieren  estudiar  y  conocer  los  ataques  que  se  pueden  realizar  a  día  de  hoy  en  redes 
lPv6,  es  fundamental  hacer  notar  que  muchas  herramientas  de  hacking  tradicionales  en 
IPv4  implementan  ya  el  soporte  para  lPv6,  Utilidades  como  nmap,  o  FOCA  dan  soporte  a 
IPv6,  pero  con  el  paso  del  tiempo,  los  pentesters  han  ido  demandando  la  aparición  de  más 
y  mejores  herramientas  que  funcionen  con  el  protocolo  IPv6. 

En  este  apartado  vamos  a  hablar  de  algunas  de  estas  herramientas  que  ya  tienes  disponibles 
para  poder  utilizar  en  las  auditorias  de  seguridad,  y  es  más  que  probable  que  sigamos 
viendo  como  aparecen  nuevas  cada  poco  tiempo. 


5.8.1.-  DOSRAStorm 

Uno  de  los  ataques  que  más  ha  sonado  en  los  medios  de  comunicación  es  el  ataque  de 
denegación  de  servicio  D.O.S.  hecho  a  máquinas  Windows  mediante  el  envío  de  múltiples 
mensajes  RA  (Router  Advertisement)  del  protocolo  SLAAC  en  el  que  se  configura  un 
gran  número  de  direcciones  lPv6,  lo  que  acaba  generando  que  las  máquinas  Windows  se 
bloqueen. 
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Fig.  5.7  L-  FlfKid  de  paquetes  RA  a  una  máquina  Windowjí. 


Este  ataque  se  conoce  desde  el  año  2010,  y  no  sólo  afecta  a  máquinas  Microsoft  Windows, 
sino  que  muchos  otros  dispositivos  IPv6  se  ven  afectados  por  el  flood  de  mensajes  RA.  El 
código  de  identificación  de  esta  vulnerabilidad  es  el  CVE-2010-4669.  Este  ataque  también 
está  implementado  dentro  de  las  opciones  de  Evil FOCA. 
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En  el  caso  de  Microsoft^  en  pruebas  con  recientes  sistemas  operativos  hemos  visto  que  se 
ha  activado  un  límite  que  evita  que  el  equipo  acabe  sin  memoria,  pero  aun  así  habría  que 
estar  atento  a  las  tormentas  de  RA  dentro  de  las  redes. 


5.8.2.-  The  TPv6  Attack  Toolkit 

Como  herramientas  centradas  especialmente  en  ataques  y  vulnerabilidades  a  redes  lPv6  hay 
que  hablar  de  The  }Pv6  Attack  Toolkit,  incorporado  en  BackTracky  Kali  y  que  contiene: 

-  Parasiteó:  realiza  ataques  MITM  con  listas  de  vecinos  spoofeados. 

-  aliveó:  escáner  que  delecta  equipos  con  IPv6 

-  dnsdictó:  realiza  ataques  de  diccionario  a  DNSvó 

-  táke_router6:  se  anuncia  un  equipo  como  router  lPv6  con  la  mayor  prioridad. 

-  rediró;  redirige  tráfico  con  icrapvó  spoofing  {man  in  the  middle) 

-  toobigb:  pennite  reducir  los  valores  MTU 

-  detect-new-ip6;  detecta  nuevos  equipos  lPv6  que  se  unen  a  la  red  y  le  pasa  un 
scñpt  al  equipo  nuevo. 

-  dos-new-ip6:  detecta  nuevos  equipos  y  le  indica  que  su  IPv6  está  repetida  en  la 
red  generando  un  ataque  D.O.S. 

-  traceb:  rápido  tracerouteb  con  soporte  para  TCMP6  echo  request  y  TCP-iSPíV 

-  nood_router6:  ataque  flood  RA  {Router  Advertisement) 

-  fiood_advertise6:  ataque  flood  NA  {Neighbor  Advertisement) 

-  fuzz  ipó;  fiizzer  para  IPv6 

-  implemcntationb:  comprueba  la  implementación  de  IPv6 

-  implementationbd:  demonio  que  escucha  implementationó  detrás  de  un  FW 

-  fake  mldó:  se  anuncia  como  un  grupo  Multicast  en  la  red 

-  fake_mld26;  lo  mismo  pero  para  MLDv2 

-  fake  mldrouteró:  envía  mensajes  falsos  de  routers  MLD 

‘  fake_m  lPv6:  roba  una  dirección  TP  móvil  si  IPSEC  no  pide  autenticación. 

-  fake  adverliseró:  anuncia  al  usuario  en  la  red. 
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-  smurf6;  local  smurter. 

-  rsmurfó:  remóte  smurfer  (solo  para  Linux) 

-  exploitó:  lanza  exploits  IPv6  conocidos  contra  un  equipo. 

-  denial6:  lanza  pruebas  de  ataques  denial-of-service  contra  un  equipo. 

-  thcpingó:  envía  un  paquete  pingó  personalizado. 

-  sendpeesó:  envía  un  paquete  especial  de  NS  {Neighbor  Solicitation)  que  hace 
entrar  la  CPU  en  thrashing  realizando  cálculos  criptográficos. 


(ánsííictc  vi. 4  (c)  by  van  v.Vrtf,thc,org 

Syritaxi  df>sííict6  J  t  íhREADS]  dcm^in  jdictiondry-filgj  ^ 

EíUii^er5te$  lí  doBair»  fcr  ms  mtrí^%j  it  ¿  dictiarjary  f 

or  a  built-ifí  orherwise.  ^ 

iJ%e  -t  specity  the  of  tnreads  to  use  íd.eféílt:  6,  fn^x:  32 )  - 

Use  just  -D  to-cíu:r;p  the  built-in  list.  ^ 

Tool  based  m  dns^sp  by  p^gvac^gnucitisen.org.  |? 

■ánsdict'b  -t  16  google.cofn 

Stisrt-ing  enuíi^eratlbg  google.cOT.  -  creatina  15  thireads  for  i80I 
£<-timdted  tiR^  lo  cQ.T.pletion:  1  tú 

lpv6.^D0gle.C0í7í.  2404: 5565:3685:.: 5a 

Fotjnclí  l  áomin  napne  mú  l  unique  Ijívb  address  for  google.cof^^  '  j 


rig.  5.72,-  dnsdlctñ  haciendo  un  ataque  de  diccionario  contra  íTaog/e.com. 


5.8.3.-  Topera  2 

'^Topera'"  es  un  escáner  de  puertos  para  ser  utilizado  con  el  protocolo  con  lPv6  al  estilo  del 
popular  nmap,  muy  simple  de  usar,  con  funcionalidad  limitada  que  ya  está  dejando  de  ser 
una  PoC  -  como  se  definía  al  principio  Es  capaz  de  realizar  un  escaneo  de  red  eludiendo 
los  sistemas  de  detección  de  intrusos  basados  en  Snort,  que  sí  que  detectan  los  realizados 
por  nmap. 

El  truco  detrás  de  Topera  2  es  que  utiliza  para  hacer  el  escaneo  extensión  headers  que 
añade  en  las  cabeceras  IPv6  para  que  cuando  se  realice  un  escaneo  de  puertos  de  SYN  este 
no  sea  detectado  por  software  de  seguridad  de  red.  Puede  descargarse  el  proyecto  desde: 
HTTP  .//íoperaprojecí.giíhub  Jo/Topera/ 
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Además  de  esta  funcionalidad,  se  le  ha  añadido  también  la  implementación  del  ataque 
Apache  Slowloris,  que  permite  hacer  ataques  de  DOS  a  servidores  Apache  no  fortificados. 
Esta  técnica  se  basa  en  generar  conexiones  que  duran  al  infinito,  y  que  generan  un  consumo 
descomunal  de  recursos  dentro  del  servidor  web. 


UNDERFliCKING#  pythori  topera, py  -t  2001:8181:11::!  -M  topera^tcp.scon  -p  20,21,22,80,8080  -e  ethl 

— - - - — - - - - - - 

I  Topera  -  IPv6  analysis  tool:  the  other  5ide  í 

I  i 

I  Project  page:  i 

I  http://toperaproject.gi.thub.lQ/toperii/  I 

I  I 

I  Daniel  Gorda  a.k.a  cr0hn  (§ggdadel)  1 

i  Rafael  Sánchez  C@i^^o_ff*a_e_ll_o>  1 

- - - - — - - 

Stqrtiiig  Topera  C  https://github,c^toperapraject/toperü  )  at  2013 -04*29  10:42:50  C£T 
Scanníng  2001:8181:11::!  [5  ports^ 

Not  shown:  3  closed  ports 

Topero  sean  report  for  2001:8181:11: :1 

PORT  STATE 

22/tcp  open 

80/tcp  open 

Topera  done:  1  IP  address  C1  bost  up)  sconned  in  0,03  seconds 

WDERFLICKIKG#  | _ j _ _ _ 


Fig.  5.73.-  Topera  tieíwork  scaiiner. 


5.8.4.-  IPv6  Toolkit  &  Iddle  scanníng  en  IPv6 

Este  es  uno  de  los  frameworks  más  populares  en  la  auditoría  de  lPv6.  Está  detrás  de  él 
Ferncmdo  Gont,  uno  de  los  investigadores  que  más  tiempo  ha  invertido  en  la  seguridad  de 
lPv6.  En  él  se  incluyen  las  siguientes  herramientas,  y  pueden  descargarse  desde  la  URL: 
//rrP://www.si6nerí\'orks.com/tools/ipv6toolkit/ 

-  addró:  Herramienta  para  el  análisis  y  manipulación  de  direcciones  lPv6. 

-  flow6:  Herramienta  para  hacer  análisis  de  seguridad  IPv6  Flow  Lahel. 

"  fragó:  Herramienta  para  hacer  pruebas  de  fragmentación  en  lPv6. 

-  icmp6:  Heiramienta  para  hacer  ataques  basados  en  mensajes  de  error  ICMPvó. 

-  jumboó:  Realiza  pruebas  en  paquetes  de  tipo  lPv6  Jimibograms, 

-  na6:  Herramienta  para  enviar  mensajes  Neighhor  Advertisemení. 
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-  ni6:  Herramienta  para  hacer  pruebas  con  mensajes  ICMPv6  Node  Information. 

-  ns6:  Herramienta  para  enviar  mensajes  Neighbor  Solicitation. 

-  ra6:  Herramienta  para  enviar  mensajes 

-  rd6:  Herramienta  para  enviar  mensajes  ICMPv6  Redirect. 

-  rs6:  Herramienta  para  enviar  mensajes  Router  Solicitation. 

-  scan6:  Scanner  de  direcciones  IPv6. 

-  tcp6:  Ataques  con  fragmentos  TCP  en  lPv6. 

Basándose  en  la  fragmentación  de  los  paquetes,  y  haciendo  uso  de  Scapy,  el  investigador 
Mathias  Morbitzer  publicó  un  trabajo  para  hacer  iddle  scanning  con  hosts  zombies  y  en  las 
redes  lPv6.  La  idea  se  basa  en  forzar  la  fragmentación  en  la  petición  de  las  conexiones  para 
poder  contabilizar  cuando  un  puerto  está  abierto,  y  enviar  la  petición  de  origen  .spoofeada. 


1  #  f /usr/h±n/pyth<m 

2  from  scapy. all  import  * 

3 

4  $th&  Áddrcases  Qf  the  three  participan ts 

5  idlahcst="<IPv6-address>'* 

6  attackar=”<IPv6-*ddress>" 

7  target*"<IPv6-addr«ss>" 

8  #  MTP'  trlLLCb  wlll  Jba  ^nnounced  ±n  thé  PTB  measage 

9  newntusi278 

10  #  ChacJtauiEi  irJiicíi  PTB  mesaagis  wiil  ¿ave 

11  checkBimEBÜsEOdaS 

12  #  t¿e  port  vhxch  is  to  sean 

13  pcr-t=‘22 

14  #  cOJi£guj-e  scapy  *3  rotitea  and  Interfaces 

15  can£  ,  i£ace€=*'ethO  '* 

16  conf ,  roiitaC .  if  add  ("ethO” ,  " : :  /O  ■») 

17 

18  #  créate  and  aend  a  fragmentad  ping  from  the  targmt  te  the  ±dle  host 

19  ping^targat^fragnvente  (IPv6  Edat=icilehost,  sre^targát)  \ 

20  /IPv6KxtHdrFragmentí)  /ICM^fiKchoHequest(i<t=123, datas" A-**  1800)  ,1400) 

21  á  and  (p  ing_targe  t  [  0  J  )  ;  sand  ( ping^tar  ge  t  E 1  ] ) 

22 

23  #  we  de  not  get  the  responso  f  so  ve  heve  to  jaaJte  ccr  atm  ene 

2 4  reipcnBe»IPv-6  {plensl248 « nh^0x3a  ^  hli4n^64 ,  src^idlahc s  t  ^  ds t^target )  \ 

25  /ICMPvÉEchoReply  (id=123  j  cksuiii?=checksum,  data*"A'’*lS00) 

26  #  taka  tha  IPv&  layer  of  the  reaponse 

27  IpvOraBponsa^response [IPv6] 

26  §  reducá  the  astount  o£  data  twing  sent  ±n  ¿ha  rsply 

29  §  (a  PTB  message  vill  only  heve  a  maxTrntim  o£  12B0  bytes) 

30  ipvérespctnse  [IPv6]  [ICHPvCEchoPeply]  .  datas^A^'*  (nemutu-Gd) 

31 

32  #  gíve  the  target  ancugh  tiaze  to  ansver 
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35  §  telX  tJi«  idie  host  that  hxs  repiy  was  too  tbe  MTO  ís  smmll^r 

36  mtu_^idlehos t_to_t«rge t=IPv6  (ds  t^idlehos t ,  src=targ« t )  \ 

37  /lCMPv6PacketTooBig  (mtijsnewmtu)  /ipv6re»pon3e 
33  #  ^end  tiie  PTfi  nt&ssage 

3  9  s  end  (iiitui_idlehos  t^to__ta  r g«  t ) 

40 

41  #  crBate  4  fragment9d  pXng  to  tbe  Idle  host 

42  fragni8nt3^£ragiiient6  (IPv€  (dfit^ldlehost  ^  src^at-baoker  ,nh=0x2c)  \ 

43  /IPv6ExtHclcPragment{)/ICMPv6EclicRequest<data="A"*1800)  ,1400) 

44 

45  #  send  tha  huge  piíig 

46  seiid  jfragmanta  [0]  )  ;  send(f  ragmenta  [ID 

47 

48  #  aend  a  spoofad  SYÜ  to  th&  ±n  tbe  Jiazzie  of  tho  idle  host 

49  syn^IPv-6  (dat^target,src=idléhost)  \ 

50  /TCP (dport=port,3portsRandMu]n{X, 8000) ,  üags="S") 

51  send(syTi) 

52 

53  i  gi  ve  the  Idlehast  some  time  to  eend  a  RST 

54  time,  sleap  (1) 

55 

56  #  aend  the  huge  plng  again 

57  send (fragmenta [0]) ;  aend (fragmenta [1 ] ) 

Fig,  5,74  -  Código  para  hacer  iddle  scanning  en  IPv6  con  Scapy. 


En  los  ataques  de  iddle  scanning^  se  engaña  a  un  host  Zombíe  para  que  haga  las  peticiones 
de  conexiones  a  la  red  al  objetivo,  evitando  así  que  se  descubra  el  originario.  Está  explicado 
el  proceso  en  detalle  en  la  revista  Hack  in  The  Box  Magazine  10  disponible  en  la  siguiente 
URL  HTTP://magazme.  kackinthebox.  org/fssiws/HITB-Ezme-Issue-Ol  O.pdf 

Para  poder  hacer  iin  iddle  scanning  es  necesario  contar  con  un  host  que  tenga  unas 
características  en  la  implementación  de  IPv6  de  forma  especial,  pero  podrían  utilizarse 
impresoras  o  terminales  móviles.  En  el  caso  concreto  de  servidores  Microsoft  Windows^ 
la  lista  de  equipos  que  pueden  usarse  como  servidor  Zombie  para  hacer  un  idloe  sean  son: 

-  Windows  Server  2003  R2  64bit,  SP2 

-  Windows  Server  2008  32bit,  SPl  y  R2  64bit,  SPl 

-  Windows  Server  2012  64bit 

-  Windows  XP  Professional  32bit,  SP3 

-  Windows  Vista  Business  64biL  SPl 

-  Windows  1  Home  Premium  32bit,  SPl  y  Ulti inate  3 2 bit,  SPl 

-  Windows  8  Enterprise  32  bit 
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5.9.-  Desactivar  IPv6  en  Windows  y  MAC  OS  X 

Si  no  se  está  haciendo  uso  de  lPv6,  lo  mejor  es  deshabilitar  este  protocolo  hasta  el  momento 
en  que  se  haga  un  despliegue  ordenado  de  él  dentro  de  ta  organización,  de  manera  consciente 
y  controlada. 

No  sir\^e  de  nada,  y  puede  ser  un  riesgo  como  se  ha  visto,  tener  IPv6  en  las  máquinas 
clientes  si  los  servidores  internos,  los  routers  de  conexión  a  internos,  o  \osJtrewalls  -  el 
propio  firewall  Microsoft  TMG  2010  -  no  soportan  e!  protocolo  IPv6. 

Deshabiliíar  IPv6  en  los  sistemas  operativos  Microsoft  ¡Vindows  es  tan  sencillo  como  entrar 
en  las  propiedades  del  adaptador  y  deseleccionar  el  protocoio  de  la  tarjeta,  lo  que  dejaría  a 
esa  interfaz  sin  soporte  para  comunicarse  haciendo  uso  de  lPv6. 


Fig.  5.75,-  Desactivar  TPv6  eE  li^itidows. 
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Sin  embargo,  en  los  sistemas  operativos  MAC  OSXdepende  de  la  versión,  mientras  que  en 
MAC  OS  X  10. 6  Show  Leopard  es  posible  deshabilitarlo  desde  las  Preferencias  de  Red,  en 
MAC  OSX 10. 7  Lion  esta  opción  no  aparece  por  defecto. 


Es  necesario  realizar  el  deshabilitado  del  protocolo  desde  el  interfaz  de  comandos,  haciendo 
uso  del  comando  networksetup  con  privilegios  de  administrador.  Primeramente  se  listan 
todos  los  interfaces  con  el  modificador  Misiallfietworkservices. 

(É  Terminal  Shell  Edición  Visuatización  Ventana 

sK-3,2#  networksetup  ^listallnetworkservices 

An  asterisk  C#)  flenotes  that  a  network  Service  is  disabled.  * 

aiuetooth  DUN 

Ethernet 

FireWire 

Wi*Fí 

sh-3,2#  networksetup  -setwEotf  Ethernet 
sh-B.2#  I 


i^ig.  5.77.-  Desatlivar  TPv6  en  un  interfaz  en  MAC  OS  X. 
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Una  vez  listados,  se  utiliza  el  modificador  -setvóqff  con  cada  uno  de  los  interfaces  en  los 
que  se  quiera  deshabililar  lPv6.  Tras  realizar  esta  operación,  el  aspecto  que  muestra  el  panel 
de  control  de  Preferencias  de  Red  es  distinto,  y  ya  aparece  la  opción  de  IPv6  desactivada 
para  el  interfaz  seleccionado. 


00  o 


Er^í«rnftt 


^¡1^^  DÑS  W^^jS  ,  SQ2.  IX  ^oxits  Hardware^ 


Conagurar  IPv4:  (  Usar  DHCP 
Oirectfórt  íPv4: 


Máscara  subred 

Aulomáticamenta 

. t 

“1 

Routtt 

i 

Manualmente 

Solo  enlace  local 

eSf  es  nccesuñó) 

Configurar  tPv6  ^  Desacttvacla 

íi) 


Cancelar  j  [  Aceptar  ] 


Fig.  5.78  -  IPv6  desactivado  en  la  intcrlay  seleccionada. 


Por  ultimo,  hay  que  recordar  que  los  sistemas  operativos  MAC  OSXo  Microsoft  Windows 
no  suelen  ser  los  únicos  que  se  utilizan  en  las  empresas  -  aunque  sí  los  más  comunes  en 
los  puestos  clientes  -  y  que  esto  debe  realizarse  en  todos  los  equipos  de  la  organización, 
ya  sean  sistemas  Linux  de  escritorio  o  ser\idor,  dispositivos  móviles  íPhorte,  BlackBerry^ 
Androidqne  se  esté  conectando  e  incluso  aquellos  sistemas  que  están  corriendo  en  sistemas 
empotrados  como  routers^  switches  o  cámaras  de  vídeo  vigilancia  !P,  Hay  que  tener  un 
control  absoluto  de  los  protocolos  de  la  organización. 


Una  buena  recomendación  de  seguridad  es  hacer  un  análisis  del  tráfico  de  red,  conectando 
un  sniffer  como  Wireshark  a  los  puertos  mirror  de  los  switches  y  así  descubrir  si  alguno  de 
los  equipos  está  anunciándose  en  la  red  TPv6  o  solicilando  peticiones  de  configuración  para 
lPv6,  y  así  saber  si  el  protocolo  está  conviviendo  o  no  en  la  red  de  la  organización. 
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Capítulo  VI 

La  protección  que  ofrecen 
los  “protocolos  seguros” 


Tal  y  como  se  ha  ido  advi ití endo  de  fornaa  previa,  los  protocolos  de  comunicaciones 
presentan  como  elemento  fundamental  la  funcionalidad  frente  a  otros  aspectos*  Estos 
hechos  fueron  los  que  originalmente  obviaran  determinados  aspectos  de  la  seguridad  y 
por  lo  tanto  ocasionaran  que  a  dia  de  hoy  se  arrastren  problemas  identificados  desde  hace 
muchos  años*  Uno  de  ellos  como  ya  se  ha  demostrado  en  el  capítulo  coTrespondiente  a 
las  técnicas  de  Sniffmg,  Spoofing  y  Hljackíng,  le  corresponde  a  la  confídencialidad  de  la 
comunicación* 

Este  capítulo  no  trata  de  ser  un  compendio  de  algorítmica,  ni  de  tune  iones  matemáticas 
de  cifrado.  De  ello  ya  se  ha  hablado  mucho  y  muy  bien  en  otros  libros.  Quiere  mostrar  no 
obstante  el  problema  visto  desde  otra  perspectiva,  la  de  la  víctima.  ¿Por  qué  puede  ser  efectiva 
una  técnica  de  suplantación  ante  un  protocolo  "'seguro”?.  Los  conceptos  matemáticos  no 
han  sido  transmitidos  convenientemente  al  usuario.  Se  le  ha  dicho  "esto  es  un  certificado  y 
sirve  para  que  te  sientas  seguro”,  sin  embargo  no  se  le  ha  dado  una  orientación  de  su  uso. 
Se  siente  confundido  cuando  accede  a  un  sitio  web  y  recibe  un  mensaje  de  que  el  sitio  no 
es  de  confianza.  Esto  sucede  incluso  con  sitios  oficiales.  En  muchas  circunstancias  no  tiene 
un  criterio  para  discernir  y  hace  que  finalmente  una  situación  potencial  mente  insegura 
la  asuma  como  algo  habitual  y  no  preste  atención  al  problema.  Aunque  se  habla  de  los 
usuarios,  también  desde  la  experiencia  que  da  años  de  formación  y  auditoría,  podría  decirse 
iguahnente  de  administradores  de  los  sistemas.  Comprenden  el  concepto  de  protocolo 
seguro,  pero  no  saben  ni  cómo  ni  por  qué  suceden  a  veces  las  cosas. 

Las  problemática  de  la  posibilidad  del  robo  de  la  información  suscitó  mucho  debate 
con  el  paso  de  los  años  y  evidentemente  el  dar  una  solución  se  convirtió  en  la  prioridad 
fundamental.  Si  las  comunicaciones  no  eran  seguras  habría  que  dotar  de  mecanismos  que 
garantizaran  la  confidencialidad  de  los  datos  en  tránsito.  La  necesidad  era  clara,  y  el  estudio 
e  implementación  requería  un  acuerdo  casi  mundial  para  tomar  ia  determinación  final. 
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Tal  y  como  había  sucedido  muchas  veces  que  cada  cual  optara  por  su  método,  era  un 
mal  método.  Era  mejor  unificar  esfiierzos  y  hacer  causa  común  para  dar  una  solución  a  la 
entonces  emergente  red  de  redes. 

La  solución  pasaba; 

-  Por  dar  una  solución  general  al  problema  de  la  seguridad. 

-  Que  pudiera  ser  implementado  por  múltiples  sistemas  y  protocolos. 

-  Que  se  apartara  de  ciertos  axiomas  concebidos  hasta  la  fecha  y  que  no  ofrecían 
más  que  una  solución  temporal. 

-  Que  permitiera  su  adaptación  según  fueran  apareciendo  nuevas  tecnologías. 


Durante  muchos  años  la  seguridad  de  una  comunicación  pasaba  por  utilizar  una  clave  de 
tipo  simétrica  y  a  través  de  una  función  realizar  el  cifrado  de  la  información  deseada.  Sin 
embargo  esto  siempre  había  generado  ciertas  suspicacias: 

-  Si  siempre  se  cifra  y  se  descifra  con  la  misma  clave,  el  transcurrir  del  tiempo  hará 
que  más  tarde  o  temprano,  pueda  ser  deducible  o  atacable. 

-  En  una  comunicación  entre  dos  o  más  interlocutores,  qué  medio  será  el  utilizado 
para  intercambiar  la  clave  con  objeto  de  que  no  pueda  ser  interceptada  y  por  lo  tanto 
deje  de  ser  útil. 


Estos  planteamientos  revestían  de  una  necesidad  que  aunque  parezca  mentira  tenía  solución 
desde  los  años  70.  En  1973  Clifford  Cocks,  matemático  de  la  Agencia  de  Inteligencia 
Británica  planteó  un  mecanismo  de  cifrado  basado  en  el  uso  de  claves  asimétrica.  Debido 
a  la  confidencialidad  de  la  idea  y  a  la  poca  capacidad  de  cálculo  con  los  que  contaban  los 
sistemas  de  aquella  época  la  idea  fue  archivada.  Años  después  con  la  desclasifícación  de 
material  secreto,  se  descubrió  que  las  bases  del  cifrado  de  comunicaciones  tal  y  como  se 
entiende  a  día  de  hoy  pudo  tener  sus  inicios  en  las  teorías  de  este  matemático. 

Sin  embargo  los  sistemas  de  cifrado  basado  en  claves  asimétricas  vieron  la  luz  en  años 
posteriores  (1976-1977).  En  1976  Whitfíeld  Difñe  y  Martin  Hellman  de  la  universidad 
de  Stanford  propusieron  un  mecanismo  de  intercambio  de  claves  entre  dos  sistemas 
desconocidos  a  través  de  un  medio  inseguro.  En  noviembre  de  1976  hicieron  público  un 
paper  denominado  New  Directions  in  Cryptography,  que  sentaba  las  bases  del  PKC  (Public 
Key  Cryptography)  y  anunciaban  el  sistema  Diffie-Hellman.  Su  trabajo  definía  algunos 
algoritmos  de  implementación  de  intercambio  de  firma  digital. 
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Aunque  su  trabajo  suponía  un  avance  significativo,  no  establecía  como  debía  realizarse 
la  implementación  de  la  fimia  digital.  Ron  Rívest,  Adi  Shamir  y  Leu  Adleman  del  MTT 
(Instituto  Tecnológico  de  Massachusetts)  describieron  el  conocido  algoritmo  RSA  (nombre 
derivado  de  las  iniciales  de  sus  apellidos)  en  1977.  El  algoritmo  daba  solución  a  los 
planteamientos  suscitados  en  cuanto  a  la  implementación  de  un  algoritmo  de  firma  digital, 
basado  en  el  producto  de  dos  números  primos. 

Puesto  que  la  base  matemática  del  algoritmo  puede  resultar  bastante  compleja,  se  reduce  el 
procedimiento  descrito  RSA  e  intercambio  PKC  para  una  fácil  asimilación. 

-  A  y  B  quieren  enviar  una  comunicación  segura,  intercambiando  información 
cifrada. 

-  Para  ello  A  posee  dos  claves  denominados  Kpub  y  Kpriv. 

-  A  envía  a  B  ¡a  Kpub.  El  proceso  se  basa  en  que  lo  que  se  cifre  con  Kpub  solo 
puede  ser  descifrado  con  Kpri  v. 

-  B  recibe  la  Kpub  de  A, 

-  B  genera  una  clave  simétrica  (clave  de  sesión)  que  será  utilizada  para  cifrar  y 
descifrar  la  infonnación  intercambiada. 

-  B  cifrará  la  clave  de  sesión  con  la  Kpub  recibida  de  A. 

-  B  envía  dicha  información  a  A. 

“  A  descifra  la  información  recibida  con  la  Kpriv.  Obtiene  asi  la  misma  clave  de 
sesión  que  posee  B  y  pueden  cifrar  la  infonnación  a  transmitir. 


Este  teorema  ofrecía  por  lo  tanto  solución  a  los  problemas  planteados: 

-  La  clave  de  la  sesión  utilizada  realmente  para  cifrar  el  contenida  a  transmitir,  era 
solamente  conocida  por  A  y  B. 

-  La  clave  de  sesión  presentaba  la  capacidad  de  ser  cambiada  en  cada  sesión  e 
incluso  en  el  transcurso  de  una  sesión  ya  establecida.  Por  lo  tanto  no  era  duradera  en 
el  tiempo  y  por  io  tanto  factible  de  ser  atacada. 


Si  el  sistema  era  considerado  como  seguro  ¿por  qué  no  utilizar  siempre  para  cifrar  !as  Kpub 
y  Kpriv,  obviando  así  las  claves  simétricas?  Simplemente  por  cuestión  de  computación. 
Hay  que  asumir  por  lo  tanto  que  el  uso  de  claves  asimétricas  no  se  da  para  cifrar  todo  el 
contenido  de  una  comunicación,  si  no  solamente  para  garantizar  la  seguridad  de  la  clave 
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simétrica  en  tránsito.  Si  esta  es  insegura,  finalmente  la  seguridad  de  la  comunicación  no 
será  buena.  El  establecimiento  de  la  negociación  de  dicha  clave  ofrecerá  finalmente  la 
seguridad  final  de  la  comunicación. 

Aunque  el  mecanismo  era  idóneo  para  garantizar  la  confidencialidad  de  la  información, 
existe  otro  aspecto  definido  ya  en  este  punto  no  menos  crítico  que  es  el  de  impedir  la 
suplantación.  El  sistema  de  claves  asimétricas  podría  además  ser  utilizado  para  garantizar 
que  algo  o  alguien  es  quien  dice  ser. 

Obviando  otros  detalles,  el  proceso  de  RSA  revestía  de  un  problema  fundamental.  Cuando 
B  recibía  la  Kpub  de  A,  ¿cómo  podía  estar  seguro  que  provenía  realmente  de  A  y  no  de  un 
potencial  atacante  que  estuviera  en  medio  de  la  comunicación?  Al  final  todo  se  reduce  a  un 
problema  de  confianza.  Confiar,  en  que  la  clave  es  de  quien  debiera. 

Puesto  que  se  había  visto  que  las  soluciones  basadas  en  la  confianza  única  no  eran  muy 
adecuadas,  implicaba  utilizar  otro  mecanismo  para  garantizar  dicho  hecho.  La  clave  por  lo 
tanto  debería  ser  única  y  exclusivamente  de  A  y  de  ningún  otro.  Aunque  este  hecho  parece 
algo  simple  de  resolver  la  cuestión  no  es  tan  trivial  como  parece. 

-  La  confianza  de  la  clave  recibida  debería  recaer  en  un  tercero. 

“  Este  tercero  debería  ser  de  confianza  para  A  y  para  B. 

-  El  tercero  debería  implementar  mecanismos  para  garantizar  la  seguridad  del 
sistema  y  que  pueda  deducirse  que  la  Kpub  de  A  es  exclusivamente  de  Ay  no  de  otro. 

-  En  caso  de  que  las  claves  pudieran  quedar  comprometidas,  plantear  mecanismos 
que  permita  indicar  a  B  que  las  claves  ya  no  son  válidas. 


Esta  necesidad  daba  paso  a  los  cimientos  de  lo  que  se  conoce  actualmente  como  PKl 
(FubUc  Key  infraestnicture).  El  estándar  X. 509  ITU-T  (International  Telecommunicatíon 
Vnion^  sector  de  las  telecomunicaciones),  fue  planteado  en  el  año  1988  en  asociación  dcl 
estándar  X.500.  El  estándar  X.509  definía  los  sistemas  PKJ  y  PMl  (Privilege  Management 
¡nfraestructure)^  con  lo  que  garantizar  la  seguridad  del  sistema  PKC  descrito  previamente. 
La  idea  fundamental  era  la  generación  de  un  tercero  que  garantizara  la  viabilidad  de  las 
claves  públicas  intercambiadas  y  la  confianza  de  las  mismas. 

La  base  era  la  generación  de  una  autoridad  certificadora  que  garantizara  la  confianza  de  las 
claves  vinculado  a  un  nombre  distinguido  declarado  a  través  del  estándar  X.500,  Así  la  idea 
fundamental  se  basaba  en  los  siguientes  elementos. 
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•  Una  serie  de  sistemas  denominados  entidades  certificadoras,  serían  las  necesarias  de 
garantizar  la  confianza  la  las  Claves  Públicas  mediante  la  generación  de  los  certificados, 

•  Los  certificados  emitidos  presentan  una  serie  de  propósitos  que  serán  interpretados 
por  el  receptor  con  objeto  de  que  puedan  ser  utilizados. 

•  La  confianza  o  no  de  la  seguridad  del  certificado  se  basa  en  tres  elementos 
fundamentales: 

-  La  confianza  en  la  entidad  certificadora  que  ha  generado  el  certificado, 

-  Que  el  certificado  emitido  para  un  propósito  (y  nombre  compieto)  se  vaya  a 
utilizar  con  dicho  fin. 

-  Que  el  certificado  pueda  ser  utilizado  en  un  margen  de  tiempo  concreto. 

•  En  el  caso  de  fallo  de  seguridad  con  los  certificados,  por  ejemplo  porque  hayan 
sido  comprometidos,  la  entidad  ceilificadora  poseerá  mecanismos  para  hacer  públicos 
todos  aquellos  certificados  emitidos  que  ya  no  sean  válidos.  La  lista  será  pública  y 
denominada  CRL  (Certifícate  Revocatíon  List). 

•  Sin  un  certificado  proviene  de  una  entidad  certificadora  desconocida  se  pondrá  en 
preaviso  ai  usuario  o  bien  se  descartará. 

•  El  sistema  implementaba  mecanismos  no  solo  para  cifrar  los  datos,  sino  para  firmar 
elementos  de  la  comunicación. 


Aunque  el  sistema  de  PKl,  está  ampliamente  extendido,  no  es  utilizado  exclusivamente  en 
todo  el  sistema  de  PKC.  Muchos  sistemas  de  cifrado  no  aprovechan  las  características  del 
servicio  PKI  para  garantizar  la  procedencia  de  las  claves.  Las  claves  se  intercambian  sin 
depositar  en  las  entidades  certificadoras  la  garantía  de  procedencia. 

El  reto  parecía  logrado,  sin  embargo  el  paso  del  tiempo  suscitó  ciertos  temores  que  se  han 
visto  reflejados  en  la  realidad.  Aunque  el  sistema  es  idealmente  seguro  ofrece  una  serie  de 
connotaciones  negativas. 

-  El  uso  de  PKÍ  de  forma  generalizada  obliga  a  la  adquisición  de  certificados  “de 
confianza’"  a  Entidades  reconocidas  mundialniente. 
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-  La  seguridad  de  los  certificados  recae  finalmente  en  dichas  Entidades 
Certificadoras.  Si  alguna  Entidad  es  atacada,  sus  certificados  emitidos  verán 
mennados  sus  ftincionalidades. 

-  Para  que  una  Entidad  sea  reconocida,  el  sistema  o  el  usuario  deberán  confiar  en 
la  misma.  Si  la  confianza  no  se  produce,  entonces  se  entiende  un  fallo  en  el  uso  del 
sistema  PKT. 

-  Si  existe  un  fallo  ¿quién  toma  la  detenninación  de  continuar  o  rechazar  la 
comunicación? 


Al  final  como  en  muchas  ocasiones  la  toma  de  decisión  podría  derivar  en  alguien  que 
no  estuviera  capacitado  para  ello.  Póngase  como  ejemplo  las  dos  siguientes  imágenes. 
Corresponden  a  la  misma  web  de  la  Agencia  Tributaria. 

La  primera  imagen  corresponde  al  acceso  realizado  por  introducir  la  URL  de  la  Web:  ww\v. 
agenciaíributaria.goh.  es 


Fig.  6,1 Acceso  basado  en  nombre. 


Sin  embargo  la  segunda  se  basa  en  haber  introducido  directamente  la  dirección  IP  del 
servidor:  195.235. 106.207 
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Fig.  6.2.™  Acceso  basado  en  iP. 

El  error  parece  evidente,  sin  embargo  el  acceso  en  las  dos  situaciones  es  totalmente 
legítimo.  En  la  primera  de  las  circunstancias  dadas  se  cumplen  las  reglas  X.509  y  en  la 
segunda  no.  El  certificado  ha  sido  emitido  para  un  nombre  distinguido,  en  concreto:  www. 
agenciaiributariü. goh.es  y  en  el  segundo  de  los  casos  se  accede  al  mismo  servidor  pero  el 
cliente  recibe  el  certificado  emitido  para  un  nombre  diferente  del  acceso  realizado:  la  TP 
195.235.106.207. 

Parece  demasiado  simple  el  ejemplo,  pero  el  problema  fundamental  radica  en  que  nadie 
ha  explicado  a  todo  aquel  que  utiliza  un  ordenador  y  se  mueve  por  Internet  las  reglas  del 
juego.  Están  acostumbrados  a  entrar  en  la  página  y  ver  el  mismo  error  que  se  muestra  en  la 
anterior  imagen.  La  palabra  clave  es  “acostumbrado”.  Asumen  por  costumbre  los  errores,  y 
por  lo  tanto  los  acaban  aceptando  como  algo  natural.  Este  hecho  se  ve  maxim izado  muchas 
veces  cuando  es  en  la  propia  organización  cuando  ven  estos  errores  al  acceder  a  servicios 
internos.  Acaban  aceptándose  simplemente,  no  se  paran  a  pensar  el  qué  está  sucediendo. 

Los  axiomas  generales  han  anunciado  siempre  que  si  hay  “S”  y  aparece  un  candado  la 
comunicación  ya  es  segura.  Bueno  pues  siguiendo  solamente  este  axioma,  lo  seguro  es  que 
un  dia  puedan  verse  estafados  electrónicamente. 
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El  problema  fundamenta!  radica  en  que  no  todo  es  tan  simple  como  parece.  Los  mensajes 
tienden  a  la  impronta  en  la  persona  de  una  acción  reactiva  ante  la  misma.  Si  se  acostumbran 
a  ver  una  imagen  recurrirán  a  ia  acción  natural.  Si  hay  error  y  doy  que  no  lo  asumo,  se  cierra 
la  ventana.  Si  hay  error  y  doy  que  sí  lo  asumo,  continúo.  Si  necesito  llegar,  más  tarde  o 
más  temprano  daré  que  lo  asumo  y  hacia  adelante.  Total  si  esto  ha  salido  muchas  veces  y 
nunca  ha  pasado  nada.  A  esto  tampoco  ayuda  que  se  llame  al  ser\dcio  de  Help  Desk  de  las 
organizaciones  y  se  le  diga  a  un  usuario  preocupado  con  la  seguridad:  “tú  dale  siempre  que 
sí,  que  no  pasa  nada  es  algo  que  tendremos  que  resolver'’. 

El  germen  del  mal  ya  está  sembrado.  Al  final  y  nuevamente,  es  un  problema  de  confianza, 
pero  en  este  caso  y  desgraciadamente  lo  más  grave  es  que  se  acaba  confiando  incluso  en  el 
error.  El  objeto  fundamental  que  se  basa  en  la  seguridad  de  la  experiencia,  fundamentada  en 
la  confianza  en  la  entidad  certificadora  puede  ser  atacado.  El  problema  por  lo  tanto  no  es  ni 
de  PKC,  ni  de  PKl  (que  son  seguros  de  por  sí),  es  simplemente  de  quien  decide  finalmente. 

El  ataque  de  hombre  en  medio  se  ha  extendido  a  los  denominados  protocolos  seguros.  Se 
puede  afirmar  qué  unprotocolo  como  HTTPS  no  es  seguro.  Realmente,  no.  La  comunicación 
es  segura  con  HTTPS  desde  origen  a  destino.  El  problema  pasa  por  definir  cuál  es  el  origen 
y  cuál  el  destino. 

¿Qué  pasaría  si  en  el  mecanismo  de  intercambio  descrito  en  párrafos  previos,  B  recibiera 
un  supuesto  Certificado  (Kpub)  emitido  por  A,  que  realmente  ha  creado  un  sistema  atacante 
intermedio?  Bueno  pues  en  el  caso  de  HTTPS,  sería  decisión  de  B  optar  por  lo  que  hay 
que  hacer  con  el  certificado,  asumirlo  o  rechazarlo.  Casi  siempre  una  comunicación  de  tipo 
HTTPS,  no  supone  ninguna  injerencia  para  el  usuario,  sucede  sin  más. 

Tomando  como  ejemplo  el  acceso  a  la  web  anterior  puede  evaluarse  el  certificado  que  ha 
desencadenado  el  proceso  PtCC.  Los  datos  existentes  en  el  certificado  y  que  de  una  u  otra 
forma  son  críticos  a  la  hora  de  establecer  la  confianza  en  el  mismo  son  los  siguientes: 

-  Nombre  sujeto  para  el  que  se  ha  emitido  el  certificado, 

-  Fecha  de  validez  del  certificado. 

-  Entidad  certificadora  que  valida  el  certificado 


El  primero  tal  y  como  se  ha  visto  previamente  supone  un  elemento  fundamental.  El  segundo 
dalo,  la  fecha,  determina  la  duración  y  por  lo  tanto  validez  del  certificado.  El  tercero  y 
último  define  quién  asegura  que  el  certificado  es  bueno.  Si  el  equipo  receptor  (o  el  usuario) 
confia  en  la  entidad  certificadora  habrá  superado  también  ese  parámetro  de  validación. 
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Fig.  6.3.-  Propiedades  del  eertiñcado. 


Fig,  6,4.-  Entidades  ceriiíleádoraíi  raí/  de  confianza. 


ISO 


Ataques  en  redes  de  dalos  lPv4  e  iPv6 


Si  cualquiera  de  los  parámetros  analizados  no  fuera  el  adecuado,  se  mostrará  un  mensaje  de 
error.  Quizá  a  veces  lo  fundamental  resida  efectivamente  en  como  se  muestra  ese  mensaje 
de  error.  A  continuación  se  muestra  el  mismo  problema,  visto  desde  tres  perspectivas 
diferentes:  Internet  Explorer  6,  Internet  Explorer  8  y  Mozilfa  Firefox.  Estos  tres  ejemplos 
ilustran  diferentes  formas  de  mostrar  el  mismo  “mensaje  de  error”  cuando  se  accede  a  la 
Agencia  Tributaria  mediante  IP  y  no  de  forma  correcta  a  través  del  nombre. 
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Fig.  6,5  - Acceso  mediante  Jnlemd  Explorer  6.0, 


E]  mensaje  que  muestra  IE6  es  bastante  descriptivo.  Muestra  el  motivo  del  error.  Quizá  el 
mayor  problema  resida  en  que  el  mensaje  descriptivo  es  demasiado  neutro  y  los  colores  en 
pantalla  (no  se  observa  el  rojo)  no  inducen  a  que  el  usuario  rechace  la  comunicación. 
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Fig,  6,6  -  Acceso  mediante  internet  Explorer  8,0. 
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En  el  caso  de  Internet  Explorer  8,  el  mensaje  ahonda  más  en  las  consecuencias  que  en  el 
problema.  Este  último  marcado  en  rojo  en  la  imagen,  puede  pasar  desapercibido  para  el 
usuario,  donde  el  foco  de  la  visión  está  desviado  a  otro  punto.  Quizás  este  mensaje  más 
negativo  condiciona  más  la  acción  del  usuario  que  en  el  caso  anterior. 


En  el  caso  de  Firefox  el  detalle  técnico  es  claro,  pero  bay  que  desplegarlo  y  como  no, 
entender  la  advertencia.  Luego  para  el  usuario  lidiar  con  el  tema  de  tas  excepciones  una  vez 
entendido  los  riesgos,  es  otra  historia. 

La  evolución  de  la  seguridad,  se  muestra  incluso  hasta  en  los  mensajes,  más  neutro  en 
el  caso  de  I.E.  6  o  más  crítico  y  dramático  en  el  caso  de  LE.  8.  Sin  embargo  todo  esto  no 
acabará  de  convencer  seguramente  por  motivo  de  la  costumbre.  El  mensaje  saldrá  muchas 
veces  ante  accesos  legítimos  y  el  usuario  acabará  entendiendo  (asumiendo  más  bien)  los 
riesgos  y  viajando  a  un  sitio  web,  seguro  de  sus  pasos. 

El  sistema  PKI  presenta  por  lo  tanto  un  problema  fundamental  que  como  no,  es  aprovechado 
para  el  ataque  de  MITM.  Por  qué  no  construir  que  la  herramienta  pueda  facilitar  al  atacante 
un  mecanismo  para  hacer  llegar  al  cliente  un  certificado  falso.  De  esta  forma  la  sesión 
podría  ser  secuestrada  “aun  siendo  segura”. 

Nuevamente  será  necesario  el  ataque  mediante  ARF  Poisoning  o  alguno  que  permita 
reconducir  el  tráfico  a  través  del  atacante.  Cuando  el  usuario  acceda  a  un  sitio  web  seguro. 
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recibirá  un  certificado  no  de  este,  si  no  del  atacante.  La  víctima  tiene  en  esta  circunstancia 
la  posibilidad  de  rechazar  el  certificado  recibido,  pero  ¿lo  hará? 

En  el  caso  de  aceptarlo,  se  estará  generando  un  doble  canal  de  HTTPS: 

-  Usuario  víctima  y  atacante:  certificado  del  atacante. 

-  Atacante  y  servidor  web  seguro:  certificado  del  servidor  web* 


La  víctima  generará  una  clave  simétrica  que  convenientemente  cifrada  enviará  al  atacante. 
Éste  que  tendrá  en  su  poder  la  clave  privada,  correspondiente  al  certificado  enviado,  podrá 
descifrar  y  obtener  la  clave  simétrica.  Con  el  certificado  del  servidor  web,  podrá  establecer 
el  canal  seguro  con  el  mismo,  garantizando  estar  en  medio  con  el  conocimiento  de  las 
claves  simétricas  necesarias  para  descifrar  y/o  alterar  la  comunicación. 

La  siguiente  imagen  muestra  dos  certificados.  El  de  la  izquierda  corresponde  con  un 
certificado  emitido  por  Caín  y  Abe!  donde  ha  interceplado  y  generado  un  certificado  para 
la  conexión  a  wwwJtotmaiLcom  que  está  realizando  una  víctima  del  ataque  de  MTTM.  El 
de  la  derecha  corresponde  con  el  mensaje  legítimo  que  se  recibe  cuando  se  accede  a  dicho 
sitio  web  y  no  hay  ataque  alguno. 


Fig.  6.8  -  Certificados  de  acceso  a  Hoímait 

Aparentemente  ambos  certificados  parecen  buenos*  Sin  embargo  en  esencia  son  muy 
diferentes  debido  fundamentalmente  a  la  entidad  certificadora  que  nos  ha  generado,  aunque 
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parezcan  ambos  emitidos  por  VeríSign  Class  3  Extended  Validatlon  SSL  CA.  La  siguiente 
imagen  muestra  confrontados  los  detalles  de  los  certificados. 
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Fig.  6.9.-  Detalles  de  los  certificados  de  acceso  a  Hotmail 


El  certificado  de  la  izquierda  es  el  falso.  Puede  verse  como  elemento  fundamental 
diferenciador,  aparte  de  la  diferencia  en  el  número  de  propiedades  existentes  en  uno  y 
otro,  la  huella  digital  del  certificado.  Este  valor  es  el  que  imprime  la  seguridad  del  uso 
del  certificado,  permite  interpretar  si  el  certificado  es  o  no  bueno  y  si  procede  o  no  de  una 
entidad  certificadora  de  confianza.  En  el  caso  de  que  la  víctima  haya  dado  por  bueno  el 
certificado,  pennilirá  que  todo  el  tráfico,  ya  descifrado,  sea  interceptado  por  el  atacante. 


fig.  6.10  -  Trállco  HTTPS  mterceptEidí.í. 
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Sera  cuestión  de  identificar  credenciales  bien  a  través  de  la  propia  herramienta  o  realizando 
un  análisis  manual  de  la  comunicación,  puesto  que  se  facilita  la  transcripción  en  texto  plano 
de  lo  que  debería  viaja  cifrado  y  “seguro”. 


==  Ca.in'3  HTTPS  aniffer  generated  file  ~ 


[Client-side-dataJ 

POST  /ppaeciiire/poat .  3r£?wa^signinl ,  0&rp3n^=lláct=132É7238Q7 
.  1 , 6206 . 0&wp=MBI£wireply=h1:tp  :  %2r%2Fmail .  live  ,  c£3m% 
2Fdefault  ^  a3pjttlc=205Sítid=64855H£inkt=e3-US£cbcxt=ínai  t3Ti3C^ltíDfc?= 
1326723979  HTTP/1.1 

Accept:  image/gif^  iraiflge/x-xbitmap,  image/ jpeg,  image/pjpeg, 
application/jc-ahockwav^e-f  laahi. 

íleferer :  httpa  :  /  /logia,  live  -  com/ppseGure/post; .  arf  ? 
wa=waigninl . 0&rp3Qv=ll&Gt=1326723Bfi7trver=6. 1.6206 ,0 
£  wp^KB  1 1  wr  epl  y=ht  tp :  %  2  2  F^a  i  1 . 1  i  ve  ,  c  Diti%  2  Pde  f  au  1 1 .  a  spx  &  1  c— 2058 

&  id=€  4855i£inXt=e3-tT3  Scbcx1:=5imi  Ssnac^l  ¿bX=13267  2  3965 
Accept-Iiaiigtiage :  es 

Content-íyp© ;  application/ x-www-f  oaa-uirlencoded 
Accept-Encodiag :  gzip,  deflate 

Üseir^Agenl; :  Mozilla/4.0  < compatible;  M3IE  6.0;  Windows  NT  5.1; 
3V1) 

Host;  login.live.com 
Coatent^I»engtK;  397 
Gonnection;  Keep-Alive 
Caobe-Control :  no-cache 

Cookie:  CkT3t=Gl32672398412a ;  wlidperf^throughput— 26laterLcy= 
1302£FR=I,fi3T=1326723967474 ;  M3PReqa=it=132 67230 93 &co=lfeid= 
64S55;  CkT3t=Gl32672309fíO94 ;  MSPOK=$uuid-ef4432b0-17d2-4b07- 
B3€6-6dl94010193a$auid-620ed4dt’3ccd-449d-8ae8*857B49e4a£52 
$aüid-f 620716b-3bf3-43d2-b0f3-6e9d£e6S32de 


[Client-side-data] 

login=j  Irmslgbotmail  -  ccjmfipasswd^xxxxxxxxxxitype^ll 
feXf  oginOp  ti  ons— 3  SNewUs  e  r—  1  &  P  P  3X=Pa  s  spo  &  PPFT=C  j  7  % 

Fig.  ó.  l  L-  Tráfico  HTTPS  descifrado. 


En  esta  circunstancia  la  decisión  de  la  seguridad  recae  sobre  el  usuario,  pero  no  siempre 
es  asi.  En  ocasiones  es  la  aplicación  o  el  mecanismo  de  servicio  planteado,  quien  decide 
si  continúa  o  no  la  comunicación  ante  la  existencia  de  un  error  de  certificado.  ¿Por  qué 
no  hacer  que  sea  la  aplicación  la  que  tome  siempre  la  decisión?  Principalmente  porque 
en  determinadas  circunstancias,  como  el  acceso  a  web  seguras,  es  el  usuario  el  que  debe 
controlar  las  condiciones  y  porque  supuestamente  el  sistema  de  PKl  es  bueno. 

Aunque  el  estándar  X.509  definió  la  figura  y  arquitectura  de  Entidades  Certificadoras, 
también  se  estipuló  que  las  mismas  podrían  ser  generadas  por  cualquier  organización.  Esto 
permitiría  a  cualquier  empresa  generar  sus  propios  certificados,  bien  para  uso  particular 
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o  para  hacerlo  extensivos  a  clientes  y  otros.  ¿Qué  diferencia  la  entidad  certificadora 
de  VeriSign  o  la  FNMT  (Fábrica  Nacional  de  Moneda  y  Timbre),  de  la  interna  de  una 
organización?  En  base  según  el  estándar  nada.  Simplemente  que  una  es  más  conocida  y 
de  confianza  para  más  sistemas  que  la  otra.  Evidentemente  salvando  las  distancias  las  dos 
primeras  tienen  unos  criterios  y  regulaciones  de  seguridad  que  seguramente  no  se  estén 
aplicando  a  la  tercera,  pero  la  funcionalidad  al  final  es  la  misma.  Si  un  sistema  confía  en 
la  privada  como  entidad  certificadora,  la  validez  de  sus  certificados  sería  equiparable  en  el 
equipo  al  de  la  FNMT. 

Es  por  lo  tanto  el  usuario  (o  el  administrador  de  los  sistemas  de  una  organización  en  la 
mayor  parte  de  las  circunstancias)  el  encargado  de  determinar  en  qué  entidades  confía  y 
en  cuáles  no.  Si  recibe  un  certificado  emitido  por  una  entidad  certificadora  en  la  que  no 
confia,  basta  con  confiar  en  ella  para  hacer  válido  lo  que  antes  no  lo  era.  Se  deja  en  manos 
del  “carbono”  la  decisión,  también  el  asumir  el  error  de  una  decisión  mal  tomada. 

Confiar  o  no  en  un  certificado  y  desviar  el  error  a  la  persona  no  es  dependencia  del  protocolo 
si  no  de  la  aplicación  que  se  utiliza.  El  siguiente  ejemplo  ilustra  un  ataque  de  MITM  de 
una  conexión  LDAP-S.  Se  muestra  la  visión  de  determinadas  aplicaciones  iniciando  la 
conexión  frente  a  un  controlador  de  dominio,  donde  las  peticiones  son  interceptadas  y  la 
sesión  secuestrada  por  un  atacante. 
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Fig.  6.12.-  CenífiemiíT  LDAP-S  interceptado. 
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La  siguiente  imagen  muestra  que  sucede  cuando  la  aplicación  LDP  de  Microsoft  intenta 
una  conexión  segura  de  tipo  LDAP  al  puerto  TCP  636  y  el  certificado  recibido  no  es  de 
confianza.  La  sesión  es  rechazada  por  repudio  del  certificado  recibido. 


Fig.  6,0,-  Sesión  l.DAP-S  rechazada  por  la  aplicación. 


En  cambio  en  la  siguiente  imagen  se  muestra  una  sesión  de  tipo  LDAP-S  para  la  búsqueda 
de  contactos  en  la  libreta  de  direcciones  a  un  servicio  de  directorios.  La  petición  ha  sido 
interceptada  por  un  atacante,  enviando  un  certificado  falso,  siendo  el  usuario  el  encargado 
de  aceptar  o  rechazar  la  conexión. 


Fíg,  6.14.-  Acceso  mediante  LDAP-S  al  contenido  de  la  libreu  de  direccioties. 
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Además  del  ataque  de  MITM,  existen  otros  posibles  vectores  de  ataque  combinados  en  el 
uso  de  los  Certificados.  Tal  y  como  se  ha  mostrado,  la  seguridad  de  las  conexiones  reside 
fundamentalmente  en  la  confianza  de  la  entidad  certificadora.  ¿Qué  pasaría  por  lo  tanto  si 
la  seguridad  de  alguna  de  ellas  pudiera  quedar  en  entredicho? 

Si  alguien  pudiera  solicitar  o  generar  certificados  para  un  nombre  concreto  sin  necesidad 
de  tener  que  validar  su  pertenencia  a  una  compañía,  podría  obtener  un  certificado  válido  y 
posiblemente  emitido  por  una  entidad  certificadora  de  las  de  “confianza”.  La  seguridad  de 
las  mismas  es  por  lo  tanto  una  garantía  de  depósito  de  todo  el  mundo.  Si  alguien  les  robara 
por  ejemplo  su  certificado  raíz,  podría  suplantarles  y  poder  generar  certificados  como  la 
propia  entidad. 

El  año  201 1  fue  notable  entre  otras  cosas  por  los  ataques  que  han  recibido  determinadas 
organizaciones.  Los  casos  de  Anonymons  o  LulzSec,  se  unen  a  otros  tantos  que  se 
realizaban  y  no  tenían  tanta  repercusión  mediática.  201 1  ha  significado  entre  otros  el  ataque 
a  Sony,  a  las  instituciones,  a  Apple,  a  famosos/as,  prácticamente  nadie  se  ha  librado,  las 
entidades  certificadoras  tampoco.  El  caso  de  DigiNotarhai  hecho  vibrar  los  cimientos  de  la 
infraestructura  PKl  significativamente. 

En  jul  io  de  20 1 1  se  produjo  una  brecha  de  seguridad  en  los  sistemas  PKI  de  esta  organización. 
Se  detectó  a  partir  de  Julio  la  presencia  de  determinados  certificados  de  tipo  Wildcard, 
emitidos  para  determinados  nombres,  Google  fue  una  de  las  más  afectadas,  y  utilizadas 
para  determinados  ataques  de  MITM.  Los  certificados  fraudulentos  fueron  finalmente 
publicados,  con  lo  que  cualquier  atacante  disponía  de  certificados  emitidos  por  una  entidad 
certificadora  de  las  reconocidas  pudiendo  ser  utilizados  para  ataques  de  hombre  en  medio. 
Puesto  que  los  certificados  son  buenos,  la  víctima  no  percibiría  el  problema  y  por  lo  tanto 
no  tendría  fonna  inicialmente  de  determinar  que  está  sufriendo  un  problema  de  seguridad. 

Debido  a  que  no  había  garantías  para  confiar  en  la  entidad  certificadora,  los  diferentes 
desarrolladores  de  Software  decidieron  sacar  sus  actualizaciones  con  objeto  de  que  los 
sistemas  rechazaran  certificados  emitidos  por  la  entidad  certificadora  afectada.  La  imagen 
de  la  página  siguiente  muestra  los  certificados  de  fabricante  considerados  de  no  confianza 
tras  la  aplicación  del  Microsoft  Security  Advisory  2607712. 

Este  mismo  hecho  fue  llevado  a  efecto  también  por  otros  fabricantes  como  Google,  Mozilla 
o  Apple.  La  seguridad  en  entredicho  de  una  entidad  certificadora  implica  un  problema  de 
seguridad  de  ámbito  global.  Pero  este  no  ha  sido  el  único  problema  que  ha  podido  poner 
en  entredicho  la  seguridad  de  PKl.  Dos  años  antes  en  la  Black  Hat  del  año  2009  Moxie 
Marlinspike  hacía  público  un  fallo  en  las  aplicaciones  que  hacían  uso  del  sistema  PKI, 
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mediante  el  uso  de  un  certificado  de  tipo  wildcard  solicitado  a  entidades  certificadoras  y 
que  en  cierto  sentido  era  casi  mejor  que  estar  en  posesión  del  propio  certificado  raíz  de  las 
mismas. 


Fig.  6, 1 5.-  Certificadüfi  revocados  de  DigiNoícir. 


Para  demostrar  el  ataque  solicitó  a  su  sitio  web  thoughtcrime.org  un  certificado  con 
el  siguiente  nombre  Jhoughtcrime.org.  Determinadas  aplicaciones,  navegadores 
incluidos,  no  evalúan  lo  que  hay  más  allá  del  valor  \0  en  un  fallo  de  funcionalidad  de  SSL, 
lo  que  implica  que  el  certificado  sería  válido  para  el  sitio  es  decir  para  cualquiera. 
Siendo  emitido  por  VeriSign  por  ejemplo,  implicaría  que  dicho  certificado  sería  válido  para 
cualquier  sitio  web,  lo  que  facultaría  para  realizar  múltiples  ataques  de  MITM, 

La  importancia  de  un  certificado  asociado  a  un  nombre  radica  en  que  si  un  certificado 
“legítimo”  es  utilizado  para  otro  nombre  que  no  se  corresponde,  aun  siendo  de  una  entidad 
certificadora  de  confianza  el  usuario  deberá  ser  advertido  de  ese  hecho.  Esto  evita  que 
certificados  buenos  sean  utilizados  en  sitios  falsos  con  nombres  diferentes  del  propósito 
para  el  que  fueron  generados* 

Sin  embargo  el  problema  anteriormente  descrito  radica  en  que  el  certífícado  es  siempre 
bueno,  independientemente  del  nombre  del  sitio  web  seguro,  puesto  que  el  valor  validado 
por  muchas  aplicaciones  es  simplemente  Lo  único  que  evalúan.  Evidentemente  las 
entidades  certificadoras  no  lo  vieron  venir  cuando  emitieron  el  certificado.  Las  aplicaciones 
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no  estaban  bien  diseñadas.  Pero  al  final  el  problema  acababa  recayendo  en  el  mismo:  el 
usuario. 

De  igual  forma  sucedería  si  un  sistema  se  ve  atacado  y  le  instalan  más  entidades  certificadoras 
de  confianza  de  las  que  inicialmente  contaba.  Si  por  ejemplo  en  los  ataques  anteriormente 
descritos  de  MITM  con  Caín  y  Abel,  e!  atacante  consiguiera  colar  entre  los  certificados 
de  confianza  de  la  víctima,  el  de  la  herramienta,  sin  duda  el  ataque  sería  un  éxito  total. 
Como  en  ei  caso  de  DigiNotar  el  usuario  no  sería  consciente  del  ataque,  puesto  que  no 
recibiría  los  mensajes  de  advertencia  del  navegador  indicando  el  fallo  en  la  aceptación  del 
certificado.  En  el  caso  de  las  aplicaciones  que  rechazan  conexiones  donde  el  certificado  no 
es  de  confianza,  pasaría  algo  similar. 

No  es  por  lo  tanto  descabellado  pensar  que  determinadas  aplicaciones  maliciosas  hacen 
ese  juego.  Manipulan  el  sistema  instalando  o  desinstalando  certificados  de  confianza.  Si 
tienen  acceso  al  contenedor  de  certificados  ¿por  qué  no  hacerlo?.  Al  final  un  mecanismo  de 
protección  quedaría  desvirtuado  por  la  confianza  del  entorno. 

Las  empresas  deben  por  lo  tanto  ser  conscientes  del  problema.  No  solamente  deben 
garantizar  que  una  comunicación  sea  realmente  segura.  Debe  ser  estrictamente  segura  según 
las  reglas  de  juego  estipuladas.  Los  equipos  no  deberán  contar  con  más  certificados  de  las 
entidades  certificadoras  de  confianza  que  los  debidos.  Deberán  atender  a  las  actualizaciones 
de  seguridad  que  ofrecen  los  fabricantes  así  como  hacer  uso  de  entornos  de  certificados  de 
confianza,  bien  utilizando  una  entidad  certificadora  externa  o  una  interna.  No  debe  asumir 
que  el  usuario  tome  por  costumbre  los  errores  de  acceso  interno  a  conexiones  HTTPS.  Y 
sobre  todo  deben  formar  a  las  personas.  Que  finalmente  sean  conscientes  de  la  problemática 
y  de  cómo  deben  actuar  al  enfirentarse  a  una  pantalla  que  les  está  diciendo  un  “no  sé  que  de 
un  problema  de  certificado”.  Puesto  que  al  final  lo  que  queda  en  la  retina  de  la  persona  es  la 
imagen  y  no  el  contenido.  La  imagen  de  error  que  muestra  un  navegador  puede  ser  similar, 
pero  los  mensajes  de  “el  nombre  no  coincide  con  el  del  sitio”  o  “la  entidad  certificadora  no 
es  de  confianza”  no  deben  tomarse  a  la  ligera. 
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Capítulo  VII 

Cuando  el  usuario  es  un  espectador 
de  la  ausencia  de  seguridad 


Una  persona  se  encuentra  en  un  hotel  navegando  a  través  de  la  red  inalámbrica  que  ofrece 
y  mirando  su  cuenta  de  Facebook,  de  pronto  en  su  cuenta  aparecen  mensajes  raros,  que  no 
está  escribiendo.  Sorpresa,  rabia  o  temor.  La  sensación  final  es  la  de  no  controlar  lo  que  está 
pasando.  Este  hecho  describe  situaciones  que  parecen  fantasiosas  pero. ..  que  se  lo  digan  a 
Ashton  Kutcher  y  su  cuenta  de  Twitter. 

Los  dos  capítulos  anteriores,  mostraban  los  problemas  derivados  de  determinados  ataques  de 
Spoofing  o  Hijacking.  La  seguridad  de  las  conexiones  de  tipo  HTTPS  u  otras  denominadas 
seguras  dependen  en  ocasiones  del  usuario,  pero  qué  pasaría  si  en  ocasiones  esto  no  fuera  ni 
así.  Si  el  usuario  no  fuera  más  que  un  mero  espectador  de  la  seguridad  y  no  fuera  consciente 
de  lo  que  pasa.  Este  hecho  es  más  habitual  de  lo  que  puede  parecer.  Por  ejemplo  cuando  se 
entra  o  se  sale  de  una  zona  con  conexión  segura. 


Fig.  7.1.-  Entrada  en  una  conexión  segura. 


Los  usuarios  son  conscientes  de  dicho  hecho  por  la  advertencia  que  ofrece  el  navegador. 
Pero  también  pueden  deshabilitar  la  advertencia.  ¿Por  qué  hacerlo?: 
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-  Porque  es  molesto  cuando  sale  de  forma  reiterada. 

-  Porque  da  igual  cuando  se  entra  o  se  sale  de  una  sesión  segura. 

-  Porque  da  igual  lo  que  ponga  si  no  se  va  a  leer. 


En  muchas  circunstancias  no  se  va  ver  el  problema  de  seguridad,  simplemente  las  cosas 
suceden  porque  sí,  son  intranscendentes  en  esencia.  ¿Qué  más  da  saber  si  se  entra  en  una 
zona  de  conexión  segura  o  se  sale?  Sin  embargo  a  veces  es  crítico  conocer  este  hecho. 
En  ocasiones  determinados  procesos  esenciales  como  el  de  autenticación  requieren  una 
conexión  de  tipo  HTTPS,  Sin  embargo  el  resto  de  la  comunicación  se  realiza  en  modo  no 
seguro.  Este  hecho  se  debe  a  que  el  cifrado  requiere  una  mayor  capacidad  de  procesamiento 
y  en  determinados  escenarios  “donde  la  seguridad”  no  es  totalmente  indispensable,  solo  se 
garantiza  lo  esencial. 

La  seguridad  en  esas  circunstancias  se  atisba,  pero  pasa  inadvertida,  con  lo  cual  su  ausencia 
no  es  a  menudo  ni  percibida.  Para  muchas  personas  los  mecanismos  de  autenticación  son 
algo  inherente  al  proceso  de  acceso  a  los  servicios.  Asumen  que  debe  ser  así  y  en  cierto 
modo  se  agradece  para  evitar  que  otros  puedan  acceder  a  su  privacidad.  Pero  normalmente 
queda  simplemente  ahí,  hay  un  usuario,  una  contraseña  y  eso  ya  está  seguro.  Si  nadie  las 
conoce,  las  cuentas  está  protegidas,  porque  los  que  implementan  el  sistema  ya  se  encargarán 
de  hacer  que  todo  sea  seguro. 

Sin  embargo  a  veces  no  hay  que  fiarse,  de  los  que  implementan  esos  sistemas.  Hay  que 
tener  en  cuenta  que  no  viven  de  la  seguridad,  que  no  es  ni  más  ni  menos  que  una  molesta 
compañera  de  viaje  que  a  la  larga  incrementa  sus  desarrollos,  la  puesta  en  producción 
y  los  costes  de  los  servicios.  Con  lo  cual  se  ajustan  a  lo  mínimo  indispensable  para  dar 
ciertas  garantías  y  que  no  se  les  pueda  tachar  de  no  apostar  por  los  sistemas  seguros.  Las 
siguientes  aplicaciones  y  métodos  que  se  van  a  describir  hablan  fundamentalmente  de  esos 
problemas,  de  cuando  la  seguridad  no  es  lo  que  preocupa  y  existen  otros  intereses.  Esa  falta 
puede  ser  aprovechada  para  la  conveniencia  de  otros. 


7.1.-  SSLStrip 

Tal  y  como  se  ha  comentado  en  párrafos  previos  la  seguridad  depende  de  múltiples  factores 
y  uno  de  ellos  es  la  seguridad  de  las  credenciales  enviadas-  El  uso  de  HTTPS  suele  ser  el 
más  empleado,  de  tal  fonna  que  las  claves  enviadas  serán  transmitidas  de  forma  cifrada 
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entre  origen  y  destino.  En  función  de  los  sistemas  empleados,  pudiera  ser  que  solamente  el 
proceso  de  envío  de  credenciales  se  estableciera  en  HTTPS,  y  el  resto  de  la  comunicación 
(anterior  y  posterior),  se  realizara  en  HTTP.  El  motivo  ya  se  ha  comentado:  ahorro  de  costes 
fundamentalmente. 

En  este  sentido  la  persona  que  está  realizando  el  proceso  de  autenticación  prácticamente  no 
será  consciente  de  ese  cambio  de  comunicación  de  no  segura  a  segura,  y  su  welta  posterior 
a  no  segura.  Es  posible  incluso  que  la  advertencia  que  proporciona  el  navegador  ante  dicho 
cambio  haya  sido  deshabilitada.  En  Black  Hat  DC  2009  Moxle  Marlinspike  presentaba  una 
herramienta  para  realizar  hijackíng  de  sesiones  HTTPS:  SSLSírip. 

El  objetivo  fundamental  que  realiza  esta  aplicación  es  forzar  a  que  una  determinada 
conexión  de  tipo  SSL  se  convierta  en  una  conexión  convencional  de  tipo  HTTP.  El  atacante 
estaría  realizando  un  secuestro  de  la  sesión  HTTPS  de  la  víctima.  La  secuencia  sería  la 
siguiente: 


-  La  víctima  establecería  conexión  HTTP  con  e!  atacante. 

-  El  atacante  realizaría  la  transformación  interna  del  tráfico  HTTP  en  HTTPS. 

-  El  atacante  establecería  la  conexión  HTTPS  con  el  servidor  web  seguro. 


El  objetivo  fundamental  es  mantener  conectividad  entre  víctima  y  servidor  web  seguro, 
pero  con  el  ataque  de  trafico  reconducido,  realizar  un  bridging  en  la  conexión.  De  esta 
forma  una  víctima  que  haya  iniciado  una  conexión  en  modo  HTTP,  es  factible  que  no 
fuera  ni  consciente  de  que  el  proceso  de  autenticación  se  ha  realizado  también  en  HTTP  El 
atacante  que  recibe  las  peticiones  podrá  almacenar  y  procesar  el  tráfico  de  autenticación  en 
HTTP  y  deberá  cifrar  conven ieníemente  la  comunicación  para  enviársela  al  servidor  web 
seguro  que  será  lo  que  esté  esperando.  En  esencia  lo  que  se  produce  es  una  degradación 
de  la  seguridad,  en  la  que  no  se  ha  ofrecido  la  posibilidad  de  negociar.  El  cliente  acepta  la 
comunicación  no  segura,  porque  sí. 

Aunque  el  objetivo  fundamental  reside  en  realizar  el  ataque  frente  a  un  proceso  de  paso 
de  comunicación  no  segura  a  segura  y  \melta  a  segura.  El  ataque  sería  efectivo  para 
cualquier  tipo  de  tráfico  HTTPS,  aunque  fuera  realizado  de  forma  inicial  ya  en  este  modo 
de  comunicación.  Automáticamente  todo  sería  transformado  en  HTTP  No  obstante  aquí 
existen  posibilidades  de  que  la  víctima  pueda  sospechar  lo  que  está  pasando.  Quizás  no 
en  comunicaciones  más  triviales,  sino  en  aquellas  que  puedan  ser  sustancial  mente  más 
críticas,  como  son  el  caso  de  cualquier  compra  online,  o  las  referentes  al  acceso  a  banca 
electrónica. 
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Para  que  el  ataque  sea  factible  es  necesario  como  en  otros  ataques  de  hljacking^  reconducir 
el  tráfico  a  través  del  atacante.  Nuevamente  las  técnicas  de  hombre  en  medio,  combinadas 
con  otras  de  capa  de  aplicación  abren  posibilidades  al  atacante. 

El  primer  paso  por  lo  tanto  consistirá  en  la  redirección  para  realizar  el  ataque  de  MTTM. 
En  el  ejemplo  siguiente  se  emplea  la  aplicación  arpspoof.  El  envenenamiento  se  realiza 
entre  la  dirección  IP  192. 168.1. 163  (máquina  víctima)  y  la  dirección  IP  192.168,1.1  que 
es  el  router  de  conexión  hacia  Internet.  Para  que  el  renvío  de  tráfico  sea  funcional,  deberá 
establecerse  dicha  condición  a  través  de  la  sintaxis  siguiente:  echo  “i  ''  >  /prvc/sys/net/ 
ip  v4/ipjbr\vard 


Fig.  12-  Ataque  de  MJTM  con  arpspoof. 

Una  vez  que  el  ataque  de  MITM  ha  sido  efectuado,  será  necesaria  la  redirección  del  tráfico 
hacia  la  aplicación  SSLStríp.  En  el  ejemplo  siguiente  SSLStrip  va  a  escuchar  las  peticiones 
en  el  puerto  TCP  10000  por  lo  que  será  necesario  renviar  las  peticiones  al  mismo.  La 
redirección  al  puerto  donde  estará  escuchando  SSLStrip  se  realiza  mediante  la  vinculación 
a  través  de  las  ipíahles^  tal  y  como  se  muestra  en  la  siguiente  imagen. 
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Kig.  7.3.-  Configuración  ik  Jpmbles  y  ejcctición  de  SSLSfrip. 


También  se  puede  apreciar  en  la  anterior  imagen  la  ejecución  de  SSLSíripy  escuchando  en 
el  puerto  mencionado.  La  información  capturada  será  enviada  en  texto  claro  a  un  fichero 
denominado  claves  JínL  log. 


Una  vez  que  el  ataque  está  puesto  en  marcha,  cuando  la  víctima  realice  una  conexión 
HTTPS,  realmente  su  perspectiva  será  de  una  conexión  no  segura  de  tipo  HTTP.  El  atacante 
tendrá  una  transcripción  de  ía  comunicación  en  claro  en  el  fichero  claves_linkJog.  El 
siguiente  fichero  muestra  una  comunicación  en  claro  del  proceso  de  acceso  de  una  víctima 
a  la  web  de  llnkedin. 


Fig.  7.4.-  Sesión  de  ¿luli^ntícación  descifrada. 

Existe  una  aplicación  que  hace  funcionalidades  de  SSL  Strip  para  ser  utilizada  en  sistemas 
Windows:  Intercepter-NG,  Agrupa  diversas  funcionalidades  para  ataques  en  redes  de  datos, 
incluidas  las  ARF  Poisonmg  e  intercepción  de  sesiones  SSL. 
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Fig .  7 . 5 .  -  Iftíercepíer-NG. 


Esta  aplicación  presenta  una  plataforma  completa  para  la  realización  de  ataques  de  redes 
de  datos  con  la  interceptación  de  datos.  Para  ello  cuenta  con  un  sistema  de  detección  de 
sistema  que  se  integra  con  las  funcionalidades  de  Man  In  The  Middle. 


Fig.  7.6”  Módulo  de  detección  de  sistemas. 
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La  aplicación  cuenta  con  el  módulo  NAT  para  los  ataques  de  redes  de  datos.  Además  de 
implementar  las  técnicas  de  MITM  otrece  mecanismos  para  técnicas  de  Hijacking: 

-  SSL  Stríp. 

-  SSL  MITM. 

-  DNS  o  ver  ICMP. 


La  primera  de  ellas  corresponde  a  la  implementación  de  tipo  SSL  Stríp  visto  en  este  punto 
desde  esta  aplicación  pero  con  el  mismo  objetivo  que  el  ya  mencionado.  La  segunda  de 
las  técnicas  es  una  implementación  del  hijacking  HTTPS  mostrado  en  el  anterior  capítulo 
DNS  over  ICMP  supone  una  técnica  basada  en  e!  ataque  de  ICMP  redirect  donde 
las  conexiones  DNS  de  la  víctima  son  redirigidas  a  través  del  interceptor.  Antes  de 
facilitar  la  respuesta  a  la  víctima,  se  enviarán  mensajes  ICMP  con  cada  IP  detectada 
en  las  respuestas  DNS,  siéndole  proporcionada  la  ruta  a  través  del  atacante. 

Cuando  la  información  de  respuesta  DNS  se  le  entregue  a  la  víctima,  contendrá  ya  una 
tabla  de  enrutamiento  conteniendo  entradas  para  los  nombres  resueltos  a  través  del  equipo 
atacante.  Este  ataque  es  una  variante  del  ataque  de  DNS  Spoofmg  en  el  que  se  alteraban  las 
tramas  que  eran  devueltas  al  cliente.  En  el  ataque  DNS  over  ICMP  no  se  altera  la  respuesta 
sino  que  se  ofrece  al  cliente  una  mejor  ruta  para  llegar  a  las  direcciones  IP  devueltas. 

La  información  interceptada  (principalmente  credenciales)  es  mostrada  a  través  del 
módulo  de  password.  Tal  y  como  se  muestra  en  la  siguiente  imagen,  aparece  una  sesión  de 
autenticación  en  Hotmail,  donde  la  víctima  ha  sido  atacada  mediante  la  funcionalidad  de 
SSL  Stríp,  combinado  con  ARF  Poisoning. 


Fig,  7.7  ~  Módulo  Password. 
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También  se  proporciona  un  módulo  convencional  de  análisis  de  tráfico  en  modo  sniffer 
donde  el  atacante  tendrá  el  volcado  de  todo  el  tráfico  capturado:  módulo  RAW.  Esto  podrá 
ser  utilizado  bien  para  un  análisis  onüne  o  para  realizarlo  posteriormente  con  otra  aplicación 
como  NeiworkMmer 
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Fig.  7.8-  (VfódtiííT  RAW. 


7.2.-  El  contenido  mixto 

Hasta  el  momento,  todos  los  ataques  que  se  han  reflejado  tenían  en  cuenta  una  conexión 
con  un  único  protocolo.  Si  es  cierto  que  se  han  podido  ir  combinando,  pero  nunca  se  han 
mezclado.  Primero  HTTP,  luego  HTTPS  y  para  finalizar  HTTP.  Pero,  ¿qué  pasaría  si  en 
una  misma  sesión,  el  usuario  recibiera  para  construir  una  página  con  contenido  y  objetos 
en  HTTP  y  con  HTTPS?.  ¿Tendría  la  capacidad  para  dilerenciarlos?. 

Lejos  de  parecer  algo  muy  peculiar,  es  más  habitual  de  lo  que  pueda  parecer.  Simplemente 
hay  que  ver  el  siguiente  mensaje  que  puede  proporcionar  el  navegador,  para  ser  conscientes 
de  la  cantidad  de  veces  qiic  puede  suceder  este  hecho. 
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Fig.  7.9.-  Advertencia  de  contenido  mixto. 


Esto  que  parece  algo  trivial,  presenta  una  transcendencia  significativa,  puesto  que  ¿cuáles 
de  los  objetos  existentes  en  la  página  son  entregados  por  conexiones  seguras  y  cuáles 
no?  En  un  ataque  muy  dirigido  y  selectivo  mediante  sslstrip,  podría  llegar  a  realizarse  el 
secuestro  de  determinados  elementos  críticos  y  ser  redtrigidos  por  HTTP,  por  ejemplo  la 
autenticación,  y  otros  sin  embargo  más  triviales  como  imágenes  ser  devueltos  por  HTTPS. 

En  este  sentido  influye  mucho  el  comportamiento  del  usuario,  y  la  configuración  que  haya 
definido  a  nivel  de  navegación.  Puesto  que  determinados  mensajes  son  molestos  ¿por  qué 
no  eliminarlos  directamente?,  total  si  no  los  va  a  saber  interpretar, 
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Fig,  7,10.-  Configuración  üel  navegador  para  conltTiido  mixto. 
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De  esta  fonna  el  usuario  podría  creer  que  la  conexión  es  segura,  sin  embargo  parte  de  la 
infomiación  estaría  siendo  enviada  en  texto  plano. 


7.3.-  FireSheep 

La  seguridad  en  ocasiones  es  demasiado  sutil  para  que  una  persona  pueda  darse  cuenta  de 
su  existencia  o  de  la  falta  de  ella.  Supóngase  que  ha  iniciado  una  sesión  en  un  sitio  web  a 
través  de  un  formulario.  Tras  un  tiempo  cierra  la  ventana  de  navegador.  ¿Cuál  ha  sido  la 
consecuencia  de  la  sesión  que  tenía  iniciada?  La  solución  es  fácil,  que  la  persona  abra  otra 
ventana  de  navegación  y  acceda  nuevamente  a  la  web.  Es  factible  que  no  tenga  que  volver 
a  introducir  la  contraseña,  automáticamente  recuperará  la  sesión  anteriormente  abierta. 

Este  hecho  que  parece  tan  frecuente,  no  causa  ninguna  preocupación,  es  algo  natural  y 
admitido  como  una  comodidad,  sin  embargo  entraña  un  riesgo  significativo.  El  sistema  ha 
almacenado  y  está  utilizando  algo  que  de  una  u  otra  forma  le  permite  identificarse  ante  el 
sistema  remoto.  Pennite  así  autenticar  la  sesión  sin  necesidad  de  facilitar  nuevamente  las 
credenciales:  la  cookies  de  sesión. 

Aunque  se  encuentran  altamente  extendidas,  presenta  un  problema  fundamental  desde  el 
punto  de  vista  de  la  seguridad  en  las  redes.  Si  un  atacante  se  hiciera  con  las  cookies  de 
sesión  de  una  victima,  podría  llegar  a  suplantarle  perfectamente.  En  octubre  de  2010  en  la 
Toorcon  12  zn  San  Diego  era  presentada  la  aplicación  FireSheep. 

Esta  extensión  para  Firefox  supuso  una  revolución  fundamentalmente  en  los  ataques  contra 
redes  sociales,  puesto  que  permitía  a  un  atacante  suplantar  a  usuarios  que  habían  iniciado 
una  sesión.  Aunque  la  idea  original  era  explotar  su  funcionalidad  en  redes  de  tipo  ÍTzFí, 
también  resulta  funcional  con  ataques  combinados  de  man  in  the  middle.  El  anonimato 
que  ofrece  la  red  WiFi  y  la  facilidad  del  ataque  lo  hace  válido  para  escenarios  tales  como 
hoteles,  aeropuertos,  centros  comerciales  o  espacios  WiFi  en  general.  Para  que  el  ataque 
sea  factible  será  necesario  que  el  envío  de  cookies  se  realice  mediante  HTTP,  cuestión  muy 
habitual  tal  y  como  se  ha  comentado  previamente,  donde  solamente  la  autenticación  se 
realiza  bajo  una  conexión  segura. 

El  atacante  necesita  disponer  de  su  tarjeta  en  modo  promiscuo  para  poder  recoger  el  tráfico 
emitido.  Una  vez  que  la  comunicación  llega  a  través  de  la  WiFi  por  ejemplo,  llega  a  la 
aplicación  FireSheep^  está  en  base  a  diferentes  Scripts,  permitirá  detectar  y  reutilizar  las 
cookies  de  determinados  sitios  web. 
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Fig.  7. 1 1 Sitios  Web  existentes  en  FireSheep. 


Hay  que  tener  en  cuenta  con  respecto  a  la  anterior  imagen  que  los  script  predeterminados 
de  la  aplicación  podrían  no  funcionar,  puesto  que  desde  la  fecha  de  desarrollo  de  la  misma 
hasta  la  actualidad,  las  cookies  pueden  haber  cambiado. 


Fig,  7.12,-  C'ookie  de  sesión  do  Facehook. 

La  siguiente  imagen  muestra  un  script  para  interceptar  y  utilizar  la  cookie  con  las  variables 
correspondientes  para  FacebooL 
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Fig.  7  J  3,-  Script  con  variables  de  Facebook. 


El  resultado  tras  iniciar  la  captura  corresponderá  con  la  aparición  de  las  diferentes 
sesiones  que  hubieran  sido  capturadas  y  para  los  que  los  Scripts  sean  funcionales. 
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Fig.  7.14.-  Sesión  inlereeptada. 


Capitulo  VIL  Cuando  el  usuario  es  un  espectador  de  la  ausencia  de  seguridad 


173 


En  la  imagen  anterior  puede  apreciarse  una  sesión  de  Facebook  interceptada  y  que  puede 
ser  aprovechada  por  el  atacante 

A  través  de  la  misma  el  atacante  podrá  interactuar  con  la  cuenta  de  la  víctima  mientras  la 
cookie  siga  activa.  En  la  mayor  parte  de  las  circunstancias  un  cierre  correcto  de  la  sesión, 
invalida  ya  la  cookie  y  el  atacante  no  podrá  hacer  uso  de  la  sesión  activa. 


Fig,  7, 1 5.-  Cierre  de  sesión. 

El  cierre  del  navegador  sin  más,  podría  implicar  que  la  sesión  esté  activa  y  por  lo  tanto 
la  cookie  tendrá  una  duración,  determinada  por  las  propiedades  de  la  misma.  En  otras 
circunstancias  las  cookies  son  persistentes  en  el  tiempo  e  implican  que  aunque  el  cierre 
de  la  sesión  se  realice  correctamente  la  cookie  sigue  teniendo  validez.  Este  mal  desarrollo 
desgraciadamente  es  algo  más  habitual  de  lo  que  puede  parecer.  Es  cuestión  de  hacer  las 
cosas  sencillas  y  cómodas,  y  reviste  un  gran  problema  para  el  usuario  de  un  sistema  aunque 
difícilmente  pueda  hacer  algo,  salvo  dejar  de  utilizarlo. 
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Está  claro  que  para  garantizar  la  confidencialidad  de  la  cookie,  lo  mejor  es  hacer  uso  siempre 
de  conexiones  de  tipo  HTTPS  y  no  solo  para  el  proceso  de  autenticación.  Conscientes  de 
este  hecho,  muchos  servicios,  redes  sociales  incluidas  como  FacebooK  admiten  el  uso 
constante  de  conexiones  seguras.  No  obstante  dejan  dicha  posibilidad  en  manos  del  usuario 
y  muchos  que  no  son  conscientes  del  problema  mantienen  las  conexiones  no  seguras.  Con 
la  seguridad  que  ofrece  las  conexiones  HTTPS  el  ataque  de  FlreSheep  queda  minimizado, 
aunque  nunca  hay  que  descartar  y  olvidar  lo  mencionado  en  el  anterior  capítulo. 

Aunque  las  contramedidas  serán  tratadas  posteriormente,  cabe  destacar  que  contra 
FlreSheep  se  desarrolló  otro  módulo  para  Firefox  denominado  BtackSheep.  Esta  aplicación 
tiene  como  objetivo  enviar  información  falseada  en  la  red  WíFU  con  unos  parámetros  de 
autenticación  falsos.  Si  hay  un  FireSheep  escuchando  en  la  red,  intentará  automáticamente 
recuperar  del  dominio  información  de  la  sesión  secuestrada,  por  ejemplo  el  nombre  del 
usuario  o  imagen  de  la  persona  con  objeto  de  proporcionarlo  por  pantalla.  Dicha  acción  será 
recogida  ^or  El ackSheep^  que  estará  trabajando  también  en  modo  promiscuo,  alertando  de 
la  existencia  de  una  dirección  IP  haciendo  uso  de  la  aplicación  FireSheep. 

Aunque  se  ha  mostrado  la  aplicación  FireSheep,  como  una  forma  de  suplantar  la  sesión, 
esto  mismo  podría  hacerse  de  forma  más  artesanal  y  por  lo  tanto  BlackSheep  ya  no  tendría 
valor.  El  gran  problema  de  centrarse  en  una  contramedida  contra  una  herramienta,  es  que 
deja  de  tener  funcionalidad  cuando  existen  varias  fonnas  de  hacer  las  cosas  y  solamente  se 
detecta  una  de  ellas. 


7.4.-  La  seguridad  está  en  la  MAC 

Tal  y  como  se  comentó  previamente  en  muchos  csceiiarios  el  control  de  acceso  está  basado 
en  validadores  estáticos.  El  usuario  y  contraseña  es  uno  de  ellos,  pero  no  es  exclusivo.  A 
veces  se  utilizan  algunos  más  simples  y  que  por  lo  tanto  presentan  mayor  posibilidad  de 
poder  ser  suplantados. 

Póngase  en  situación.  Se  encuentra  en  un  hotel  y  desea  conectarse  a  Internet,  pero  resulta 
que  cuando  va  a  iniciar  su  navegador,  se  encuentra  con  la  sorpresa  de  que  hay  que  pagar 
por  el  servicio...  15£  diarios.  Bueno  es  una  necesidad  imperiosa  y  no  hay  alternativa,  así 
que  se  encamina  a  la  recepción  para  solicitar  el  acceso.  Tras  hablar  con  el  recepcionisla  este 
le  facilita  el  código  de  acceso  vinculado  a  su  cuenta  del  hotel.  Sube  a  la  habitación  abre  el 
navegador  y  tras  introducir  el  código. . .  está  navegando  por  liilernet.  Tras  un  tiempo  apaga 
el  equipo  y  sale  a  dar  una  vuelta.  Al  volver  \Tielve  a  encender  el  equipo  y  abre  nuevamente 
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el  navegador  para  introducir  la  clave,  pero.,,  no  se  le  solicita,  simplemente  está  navegando 
nuevamente  por  Internet. 


¿Qué  ha  pasado?  ¿Cómo  sabe  quién  soy?  Simple,  está  utilizando  un  validador  estático 
ya  proporcionado  y  que  el  sistema  que  proporciona  el  acceso  de  conexión  inalámbrica  ha 
almacenado  y  está  utilizando.  Parándose  a  pensar  en  las  posibilidades,  debería  ser  algo 
invariable  dentro  de  la  comunicación  y  que  sea  genérico  o  estándar,  puesto  que  en  el  equipo 
no  se  ha  instalado  ninguna  aplicación.  El  nombre  de  máquina,  imposible.  La  dirección  ÍP, 
improbable.  Es  más  si  se  el  inquilino  del  hotel  se  fijara,  se  daría  cuenta  que  en  cada  inicio 
del  equipo  se  le  proporciona  una  nueva  TR  ¿Qué  quedara*.  .*? 


Pues  ese  elemento  que  llevan  todos  los  dispositivos,  los  hace  únicos  y  han  quedado 
grabado  a  fuego  desde  la  fábrica,  la  dirección  MAC*  Nuevameiile  demasiados  axiomas. 
Existe  ia  creencia  más  o  menos  generalizada,  incluso  en  la  comunidad  informática,  de 
que  la  dirección  física  es  un  valor  único  e  “inalterable”  que  utiliza  todo  dispositivo  de  red, 
incluidas  las  NIC  {NetWork  Interface  Card).  Sin  embargo  eso  está  muy  lejos  de  la  realidad. 
Los  sistemas  Linux  cuentan  con  la  propia  aplicación  ifeonfig  para  realizar  el  cambio  de  la 
misma. 
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rig.  7.16.-  Cambio  de  dirección  MAC  en  un  siskina  Limx. 


En  el  caso  de  los  sistemas  operativos  Microsoft,  aplicaciones  de  terceros  o  el  propio  driver 
de  la  tarjeta  permitiría  el  cambio  de  la  misma.  A  través  de  las  propiedades  de  la  tarjeta 
de  red  puede  realizarse  el  cambio  a  cualquier  dirección  física  válida.  Este  cambio  es 
persistente  a  nivel  de  sistema  operativo,  de  tal  forma  que  invalida  el  valor  proporcionado 
por  el  fabricante. 
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Fig,  7.17.-  Cambio  de  d3rf;ct;ión  MAC  a  travos  de  las  propiedades  del  driver. 


Con  esta  información  en  posesión  del  atacante  y  escuchando  en  la  red  WiFi,  que  como  no 
estará  totalmente  en  abierto,  se  podría  escuchar  el  tráfico  y  reutilizar  una  de  las  direcciones 
físicas  que  estuvieran  saliendo  hacia  Internet,  La  cuestión  a  plantear  es  si  dos  direcciones  IP 
diferentes  podrán  tener  la  misma  dirección  física.  La  respuesta  es  sí  puesto  que  un  mismo 
adaptador,  con  una  única  MAC,  puede  tener  múltiples  direcciones  TP.  Los  sistemas  de 
autorización  WiFi,  ¿serán  conscientes  del  hecho  de  que  dos  IP  diferentes  están  haciendo 
uso  de  la  misma  dirección  física  y  bloquearán  una  de  ellas?  ...  Afortunadamente  para  la 
victima,  ha  pagado  solo  1 5€  y  no  en  base  al  tráfico  que  llegue  a  utilizar. 

El  uso  de  la  MAC  como  valtdador  estático  es  más  habitual  de  lo  que  parece,  sin  embargo 
no  debe  considerarse  como  una  medida  estricta  de  seguridad.  Sí  como  una  más,  pero  no 
la  única.  Sin  embargo  se  da  como  medida  de  protección  en  los  dispositivos  de  red.  Los 
Switch  suelen  presentar  como  mecanismo  la  característica  de  Fort  Security.  A  través 
de  la  misma  a  un  puerto  se  le  vincula  una  determinada  dirección  MAC.  Si  un  atacante 
quisiera  utilizar  su  equipo  en  vez  del  que  existe  en  la  empresa,  podría  suceder  que  bien 
la  conexión  no  se  realizara,  que  el  tráfico  ñiera  rechazado  o  la  opción  más  estricta,  que  el 
puerto  quedara  bloqueado.  La  última  es  la  más  eficaz  puesto  que  el  administrador  de  la  red 
quedaría  advertido  de  la  incidencia,  eso  sí,  aumentaría  mucho  el  coste  de  administración 
de  la  inífaestructura. 
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Un  atacante  avezado,  antes  de  realizar  el  cambio  de  equipo  debería  haber  averiguado 
previamente  la  dirección  física  del  equipo  conectado  a  la  red,  para  ser  utilizado  en  la 
máquina  atacante.  De  tal  forma  que  cuando  esta  nueva  máquina  entrara  en  la  red,  no  sería 
rechazada  por  la  electrónica  de  red.  Si  en  este  momento  está  pensando  en  por  qué  el  atacante 
va  a  utilizar  una  máquina  diferente  de  la  existente  en  la  red,  es  que  no  posee  “mirada  sucia”. 

-  Para  enmascararse  mejor. 

-  No  dejar  huellas  en  un  sistema  propiedad  de  otro. 

-  Poder  utilizar  el  sistema  operativo  que  más  le  convenga. 

”  Hace  uso  de  un  arsenal  ilimitado  de  aplicaciones. 


Una  seguridad  similar  la  proporcionan  los  puntos  de  acceso  inalámbricos.  Estos  autorizan 
la  conectivídad  a  determinadas  estaciones  que  coincidan  con  unas  direcciones  físicas 
almacenadas  en  sus  tablas  locales. 


Nuevamente  como  en  el  caso  del  hotel  el  atacante  debería  activar  la  escucha  y  determinar 
direcciones  físicas  que  se  estuvieran  comunicando  hacia  Internet.  E!  cambio  de  dirección 
en  la  máquina  atacante  facultaría  para  que  la  conexión  fuera  efectiva.  Este  mecanismo 
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evidentemente  no  puede  ser  tomado  únicamente  como  mecanismo  de  seguridad,  puede 
ayaidar  pero  por  éi  mismo  no  ofrece  garantías. 

Utilizado  junto  con  una  clave  WEP  ( Eqiúvalent  Privacy\  curioso  nombre  visto  desde 
la  perspectiva  del  libro,  seguridad  equivalente  a  la  red  cableada),  requiere  que  el  atacante 
tarde  un  tiempo  en  obtener  la  clave  utilizada  y  darse  cuenta  de  que  no  sale  por  ia  protección 
de  filtrado  MAC.  No  está  al  alcance  de  todos  pero  la  información  ya  existe.  Sumado  a  un 
WPA2  (JViPl  Protected  Access)  con  una  clave  consistente  puede  tener  más  sentido,  pero  lo 
mismo  ya  no  es  necesario  el  filtrado  de  MAC. 

Tal  y  como  se  ha  visto  el  problema  de  los  vaiidadores  estáticos  es  que  si  los  descubren  dejan 
de  tener  funcionalidad.  Todo  depende  por  lo  tanto  en  estas  circunstancias  de  la  sagacidad 
del  atacante. 
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Capítulo  VIII 
Protección  frente  a  ataques 


Tal  y  como  se  ha  estado  describiendo  a  lo  largo  de  muchas  páginas  los  ataques  en  las 
redes  de  datos,  lejos  de  parecer  algo  del  pasado,  se  encuentran  en  una  constante  evolución. 
Nuevas  aplicaciones  y  nuevas  técnicas  para  robar  información.  La  aparición  de  nuevos 
protocolos  no  parece  que  esto  pueda  hacer  cambiar.  Por  lo  tanto  no  quedará  más  remedio 
que  aplicar  contramedidas. 

Hay  que  tener  en  cuenta  que  i mpl ementar  seguridad  tiene  un  coste:  aplicaciones,  adquisición 
de  mejor  electrónica  de  red,  mayor  tiempo  de  administración,  etc.  Y  las  contramedidas 
como  no,  van  enfocadas  a  eso.  Aunque  el  coste  no  sea  tangible  está  ahí.  Implementar  algo 
como  IPscc,  puede  parecer  que  no  presenta  un  coste  inicialmente,  sin  embargo  el  coste 
derivado  de  la  administración  y  el  soporte  es  algo  que  también  puede  cuantificarse,  aunque 
seguro  que  no  los  dolores  de  cabeza  que  puede  dar  el  intentar  dar  una  solución  a  algo  que 
no  se  conoce  muy  bien. 

La  protección  tiene  diferentes  direcciones,  siendo  algunas  más  efectivas  que  otras.  Quizás 
sea  la  combinación  de  varias  la  que  den  la  clave  para  evitar  los  problemas.  Las  soluciones 
que  se  plantean  pasan  por: 

-  Garantizar  la  confidencialidad  de  la  información.  Las  cuestiones  son  dónde  y  con 
qué  fin. 

-  Proteger  contra  determinados  ataques  como  tos  de  ARP  Poísoning.  Sí  pero  hasta 
cuándo  y  con  qué  alcance. 

-  Oü'as  pueden  ser  detectar  los  ataques  o  las  herramientas.  Sí,  pero  hay  que  tener  en 
cuenta  que  todo  es  cambiante. 

Las  medidas  tienen  además  que  ser  adaptativas  e  ir  progresando  con  la  tecnología.  Medidas 
de  protección  de  hace  muchos  años  a  día  de  hoy  no  tienen  validez.  Ya  se  expuso  el  ejemplo 
de  las  soluciones  fírevvall  en  la  protección  del  perímetro.  Al  final  cada  empresa  debe  buscar 


180 


Ataques  en  redes  de  datos  fPv4  e  IPv6 


el  equilibrio  entre  su  necesidad  y  su  beneficio.  Si  el  coste  de  la  seguridad  está  muy  por 
encima  del  riesgo  que  puede  asumir,  es  probable  que  no  le  compense  aplicar  determinadas 
medidas  de  seguridad. 


8.1.-  Seguridad  por  oscuridad.  IPsec 

Cuando  se  estaban  definiendo  las  características  con  las  que  contaría  la  nueva  versión  de 
IP,  se  establecía  también  la  base  de  lo  que  debería  sentar  las  bases  para  la  arquitectura  de 
seguridad  del  Protocolo  de  Internet  (IPsec).  En  agosto  de  1995,  se  hace  pública  la  RFC 
1825  que  sentaba  las  bases  para  la  implementación  de  un  sistema  que  permitiera  dotar  de 
confidencialidad,  garantizando  el  origen  y  el  destino  de  una  comunicación. 

IPsec  es  un  elemento  de  la  comunicación  nativo  para  IPvó  y  opcional  para  IPv4,  que 
proporciona  ti*es  características  fundamentales: 

-  Finnado  de  los  paquetes  para  garantizar  la  no  alteración  del  mismo. 

-  Cifrado  de  parte  del  contenido  de!  paquete  para  garantizar  su  confidencialidad. 

-  Autenticación  mutua  de  los  sistemas  que  intervienen  en  la  comunicación. 


IPsec  se  diferencia  tundamentalmente  de  otros  protocolos  seguros  en  que  otorga  estos 
mecanismos  de  seguridad  en  capa  3.  Es  por  lo  tanto  diferente  de  otros  como  FITTPS  que  lo 
hace  a  nivel  de  aplicación  para  protocolos  completos.  Así  con  IPsec  todos  los  protocolos  de 
capa  4  y  5  dentro  de  la  pila  TCP/IP  podrían  ser  garantizados. 

IPsec  es  conocido  habitualmente  en  la  implementación  de  túneles  VPN.  Sin  embargo 
también  puede  ser  utilizado  para  garantizar  la  seguridad  en  una  red  de  área  local.  En  función 
del  modo  de  operación  de  IPsec  se  pueden  distinguir  dos  formas  básicas: 

-  Modo  transporte.  El  Payload  del  paquete  IP  es  cifrado  y  autenticado.  El 
enrulamiento  permanece  intacto  puesto  que  no  se  modifica  la  cabecera  IP.  Sin 
embargo  si  el  paquete  va  firmado  {existe  la  posibilidad  en  IPsec  de  que  no),  no  puede 
alterarse  las  direcciones  IP  puesto  que  invalidaría  el  hash.  Este  modo  es  utilizado 
para  !a  comunicación  de  equipa  a  equipo. 

-  Modo  túnel.  En  este  modo  todo  el  paquete  desde  la  capa  tres  hacia  las  superiores, 
son  cifradas  y  firmadas.  Para  que  éste  llegue  a!  destino  se  encapsula  en  un  nuevo 
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datagraraa  IP  para  que  pueda  ser  enrulado  al  destino.  Este  mecanismo  es  el  empicado 
frecuentemente  para  el  establecimiento  de  VPN  entre  sitios  o  la  comunicación  de 
clientes  VPN. 


En  función  del  escenario  en  el  que  se  encuentre  una  organización  podrá  emplearse  uno  u 
otro  mecanismo.  Póngase  por  ejemplo  la  circunstancia  en  la  que  en  un  hospital  el  acceso 
de  la  aplicación  de  los  médicos  a  la  base  de  datos  de  historiales,  se  produce  mediante  una 
conexión  sin  cifrar.  En  el  desarrollo  de  la  aplicación  no  se  tuvo  en  cuenta  este  problema  y  el 
cambio  de  la  misma  resulta  inabordable.  En  este  contexto  para  garantizar  la  confidencialidad 
de  los  datos,  podría  optarse  por  asegurar  el  contenido  mediante  la  aplicación  de  IPsec. 

IPsec  en  este  sentido  es  bastante  maleable.  Cuando  se  piensa  en  IPsec  muchas  veces  se 
compara  automáticamente  con  las  VPN,  pero  el  concepto  es  mucho  más  amplio  y  flexible. 
Con  IPsec  no  todo  tiene  que  ser  cifrado.  Si  por  ejemplo  la  aplicación  de  las  máquinas  de  los 
médicos  utiliza  un  puerto  específico  para  comunicar  con  la  base  de  datos,  podria  asegurarse 
exclusivamente  eso,  la  comunicación  del  puerto  o  puertos  de  los  equipos  de  los  médicos 
hacia  los  servidores  de  base  de  datos  que  escuchan  en  un  puerto  o  puertos  concretos.  El 
resto  de  la  comunicación  podría  ir  perfectamente  sin  cifrar. 

IPsec  da  cabida  a  dos  protocolos:  ESP  {Encapsulaüng  Securlty  Payload)  y  AH 
(Auíheníication  Ueader). 

-  ESP  es  dentro  de  IPsec  el  encargado  de  proporcionar  la  confidencialidad  de  los 
datos  y  la  autenticación  de  los  sistemas  que  establecen  la  comunicación  segura. 
También  permite  el  firmado  de  los  paquetes.  Utiliza  de  forma  convencional  el  puerto 
IP50. 

-  AH  es  el  encargado  de  garantizar  la  integridad  de  los  datagramas  y  también  de 
la  autenticación  y  el  no  repudio,  pero  no  ofrece  confidencialidad.  Utiliza  de  forma 
convencional  el  puerto  IP  5 1 . 


Aunque  la  forma  común  es  emplear  ambos  mecanismos  de  forma  conjunta,  pueden  ser 
utilizados  indistintamente  con  objetivo  diferente.  La  combinación  de  ambos  evita  el 
sniffing,  Spoqfing  (en  determinadas  capas)  y  el  hijacking. 

La  implementación  de  IPsec  en  los  sistemas  operativos  se  realiza  mediante  la  configuración 
de  aplicaciones  o  servicios  del  driver  de  IPsec  existente  en  las  librerías  de  TPC/IP.  En  el 
caso  de  los  sistemas  Linux  es  empleado  habitualmente  el  paquete  racoon. 
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root@bt: 


¡Package  confi'^yratictn 


Con figu ring  racoofl 


RacQon  can  be  configured  two  ways,  either  by  fJirectly  editing 
/etc/racoon/racjiron-Conf  or  using  tbe  nacoon-tool  adininistrative  front 
end.  racoon’tool  Is  new  depreca ted  and  is  only  available  for  hackward 
coínpatibility.  Tíew  installations  should  aliíays  use  the  "direcf'  method, 

Configuration  mode  fer  racoen  IKE  daemon. 


rscoon-tool 

<úk> 


Configuración  de  Racoon, 


A  través  del  fichero  de  configuración  pueden  establecerse  los  mecanismos  empleados  para 
la  negociación,  autenticación  y  en  general  para  la  conexión  IPsec. 


Fig.  8,2,-  Fichero  de  configuración. 
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En  el  caso  de  los  sistemas M/ctoío/í  la  configuración  de  IPsec  seha  realizado  tradicionalmente 
a  través  de  las  políticas  de  grupo. 


Fig.  8.3,-  Cóiiíiguración  por  políticas. 


No  obstante  en  las  últimas  versiones  puede  sertambién  realizado  a  través  de  la  configuración 
de  la  consola  del  firewall  avanzado. 


Fig.  8.4.-  Conílguración  JPscc  a  través  de  la  consola  del  Firewall  en  modo  avanzado. 
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El  proceso  de  implementación  de  IPsec,  pasa  por  definir  una  serie  de  conceptos: 

-  Determinar  que  se  quiere  asegurar. 

-  Qué  tipo  de  modo  se  quiere:  transporte  o  túnel. 

-  Definir  el  mecanismo  de  autenticación  mutua  a  emplear. 

-  Definir  los  algoritmos  que  serán  negociados  por  los  sistemas,  lanío  para  firmar 
como  para  cifrar  el  contenido  a  transmitir. 


El  proceso  de  autenticación  garantiza  que  los  intervinientes  en  la  comunicación  son  quienes 
deben  ser.  De  esta  forma  si  algún  sistema  no  se  ha  autenticado  correctamente,  podrá  ser 
rechazado  consecuentemente.  Para  que  la  comunicación  sea  efectiva  la  autenticación  debe 
ser  mutua,  permitiendo  IPsec  que  cada  cierto  tiempo  los  sistemas  tengan  que  volver  a 
autenticarse,  Esto  evita  un  problema  conceptual  de  las  comunicaciones  que  permite  que 
alguien  que  haya  secuestrado  una  transmisión  en  la  que  se  haya  producido  la  autenticación 
inicial,  pueda  eliminar  a  uno  de  los  dos  sistemas  y  continuar  la  comunicación,  puesto  que 
ya  no  se  requiere  nuevamente  que  sea  autenticado. 


Fig,  Sistemas  de  amen  ü  cae  ion. 
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Los  procesos  de  autenticación  utilizados  para  IPsec  tradicional  mente  son  dos*  Una  clave 
PSK  (Pre^Shared  Key)  o  el  uso  de  certificado  (PKI)*  En  los  sistemas  Microsoft,  dentro  del 
territorio  Kerberos,  se  admite  también  el  uso  de  tickets  para  el  proceso  de  autenticación  y 
la  autenticación  de  tipo  NTLMv2.  No  obstante,  dicho  mecanismos  no  son  considerados 
un  estándar,  por  lo  que  existiría  problemas  de  autenticación  con  sistemas  no  Microsoft. 
Otros  fabricante  podrían  definir  sus  propios  sistemas  de  autenticación  aunque  lo  estándar  y 
compatible  es  el  uso  de  clave  PSK  o  Certificados. 

Tal  y  como  se  ha  ido  viendo  la  evolución  en  la  seguridad  ha  ido  trayendo  nuevos  algoritmos 
que  sustituyen  a  algunos  que  ya  han  podido  quedar  expuestos  a  ataques*  En  la  vida  útil  de 
los  sistemas  operativos,  implica  que  de  los  diferentes  existentes,  solo  conocen  y  pueden 
utilizar  un  detemimado  número  de  ellos.  Puesto  que  existe  la  necesidad  de  vincular  múltiples 
sistemas  a  través  de  IPsec,  estos  deberán  negociar  los  algoritmos  a  emplear.  Evidentemente 
se  trata  de  seguridad  al  alza,  donde  lo  idóneo  es  utilizar  los  más  seguros,  sin  embargo  no 
todos  los  sistemas  pueden  implementarlos. 


Fig.  8.6.-  r>efinit;ión  de  algoritmos. 

El  proceso  de  autenticación,  negociación,  e  intercambio  de  claves,  se  deja  en  manos  del 
protocolo  \SAKM? {Internet Security Assúcíation  andKeymanagementProtocoí).  Definido 
a  través  de  la  REC  2408  defíne  el  estándar  de  intercambio  de  las  claves  utilizado  más 
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comúnmente:  IKE  {Interneí  Key  Exchange).  Este  sistema  utiliza  el  mecanismo  de  Diffie- 
Hellman  ya  mencionado  previamente  para  generar  e  intercambiar  las  claves  utilizados 
en  el  proceso.  Se  realiza  en  dos  fases:  la  fase  principal  con  una  única  asociación  (SA) 
bidireccional  y  la  fase  dos  o  modo  rápido  donde  se  generan  un  mínimo  de  dos  asociaciones 
unidireccionales. 


Fig.  8.7.-  Comunicación  ISAKMP, 


Las  asociaciones  realizadas  por  un  sistema,  los  algoritmos  está  empleados,  así  como  las 
diferentes  estadísticas  pueden  ser  consultados  con  herramientas  específicas.  En  el  caso  de 
los  sistemas  Microsoft  se  puede  realizar  a  través  del  monitor  de  seguridad  IP,  tal  y  como  se 
ve  en  la  primera  imagen  de  la  página  siguiente. 


IPsec  tal  y  como  ya  se  ha  comentado  ofrece  mucha  ti  ex  ib  il  ¡dad  en  cuanto  a  su  implementación . 
De  tal  forma  que  en  el  proceso  de  negociación,  pudiera  ocurrir  que  un  sistema  no  tuviera 
configuración  IPsec.  Puesto  que  la  condición  que  podría  llegar  a  marcarse  es  que  prevalezca 
la  comunicación  frente  a  cualquier  otra  cosa,  podría  admitirse  incluso  una  comunicación 
no  segura. 
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Fig.  8-8  -  Monitor  de  seguridad  IR 


A&istente  para  acciona  áe  filtrado 


Comnc^idetón  con  eqiipos  no  conip^íbles  con  IP^oc 

Comuntcarse  con  equipos  que  no  son  cofnpatibles  con  IPsec  puede  afTieagar  ía 
SÉsguridad  de  su  red. 


f,Desea  p^mitir  ía  copnunicaíaón  con  equipos  no  coffipatibles  con  3Psec? 

<• .  Mo  parmíirla  comunteadón  no  sagura. 

C  Pefínitir  comunicación  no  segura  st  no  se  puede  establecer  una  coneflón  segura 

Use  opción  si  ságún  equipo  en  Ja  red  no  es  comp^iblo  con  iPseo  o  rvo  t»ne 
una  conf^uradón  IFsec  oompatífaie.  Si  permite  ta  corminicaoién  no  segura,  la  red 
podría  exponerse  a  dgün  nesgo  de  seguridad. 

En  un  equipo  con  WndüWfi  o  una  vereran  posterior  de  Windows,  esta  opción 
p«miíe  que  se  establezca  una  cofnunicacwn  no  segura  cada  vez  que  no  ae  pueda 
establecer  una  conexión  segura. 

&i  equipos  íx>n  VVindoivgi  HKiO,  Vifindowa  XP  o  Wrtdows  2003,  esta  opción 
pennite  que  b  coriiL»5ícedón  no  segura  se  envíe  sob  cuando  d  equipo  remoto  no 
gea  compdide  con  iPsec. 


<  Arás  I  Siguiente  >  [  Canodar  | 

Fig.  S.9.-  Conexión  flexible. 

Tal  y  como  se  muestra  en  la  imagen  anterior  una  conexión  de  seguridad  podría  llegar 
a  negociarse  de  tal  forma  que  si  un  sistema  puede  y  utiliza  IPsec  podría  emplearse 
comunicación  segura.  Si  no  es  capaz  de  llegar  a  negociarse  la  comunicación,  esta  podría 
llegar  a  establecerse  de  forma  convencional  sin  la  intervención  de  IPsec.  No  obstante 
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para  las  comunicaciones  altamente  críticas  puede  tomarse  la  detenninación  de  emplear 
exclusivamente  comunicación  segura,  de  tal  fonna  que  si  la  negociación  no  es  factible,  no 
se  realizará  el  intercambio  de  paquetes. 

De  esta  forma  y  a  través  de  la  configuración  del  driver  de  IPsec  se  podrían  llegar  a 
configurar  múltiples  comunicaciones.  Algunas  de  estas  serán  más  seguras  con  máquinas 
concretas,  haciendo  uso  de  un  determinado  mecanismo  de  autenticación.  Para  otras  en 
cambio  menos  críticas,  podría  optarse  por  la  seguridad  si  hay  negociación  y  si  no,  el  método 
de  comunicación  tradicional.  Para  aquella  relación  entre  sistemas  muy  sensibles,  toda  la 
comunicación  será  cifrada,  sin  embargo  para  entornos  donde  sólo  es  crítica  la  comunicación 
de  una  aplicación  a  un  servicio  concreto,  habría  que  garantizar  ese  mínimo  indispensable. 

Una  vez  que  la  negociación  ha  sido  satisfactoria,  y  la  comunicación  se  ha  establecido,  lo 
único  visible  desde  el  punto  de  vista  del  atacante  son  tramas  de  tipo  ESP. 


Fig.  K.  10.-  Tráfico  liSP, 

En  esencia  el  atacante  no  es  capaz  de  distinguir  el  tipo  de  comunicación  que  se  está 
estableciendo.  Bien  podría  ser  una  comunicación  ICMP,  el  acceso  a  un  fichero  por  la  red 
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o  la  autenticación  vía  formulario  en  la  intranet  de  la  organización.  La  imagen  siguiente 
muestra  la  descomposición  de  la  trama,  revela  la  visibilidad  de  la  nueva  cabecera  IP  que 
identifica  la  comunicación  de  tipo  ESP  y  el  Payload  correspondiente  a  las  antiguas  capas 
3,  4  y  5,  encapsuladas,  firmadas  y  cifradas. 


Fig.  K.  n  Descomposición  de  una  trama  ESP 

IPsec  por  lo  tanto  constituye  un  sistema  significativo  para  la  protección  de  las 
comunicaciones.  Realmente  no  solventa  por  ejemplo  el  ataque  de  ARP  Poisoning.  Este 
ataque  se  produce  en  la  capa  2,  e  IPsec  firma  y  cifra  la  capa  3  y  superiores.  Por  lo  tanto  el 
ataque  de  puede  seguir  produciéndose,  pero  el  efecto  colateral  de  aplicación 

de  IPsec  es  que  anula  las  consecuencias  posteriores  del  ataque,  análisis  y  modificación  de 
la  información  en  tránsito. 

IPsec  supone  una  apuesta  interesante  para  las  redes  locales  de  las  organizaciones,  sin 
embargo  estas  tienen  que  tener  en  cuenta  algunas  consideraciones.  El  primer  pensamiento 
de  una  empresa  pasará  seguramente  por  cifrar  todas  las  comunicaciones.  Sin  embargo  hay 
que  valorar  el  coste  en  procesamiento  de  tanta  información;  ¿estarán  los  sistemas  (y  el 
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hardware)  preparados  para  dicha  carga?  También  existen  dispositivos  en  la  red  que  pudieran 
no  entender  ni  negociar  IPsec.  Por  ejemplo  impresoras,  cabinas  de  red,  sistemas  de  copia  de 
seguridad  o  la  propia  electrónica  de  red. 

También  cifrar  implica  perder  capacidad  de  análisis*  Si  la  inlbrmación  se  encuentra  cifrada 
los  sistemas  de  detección  de  intrusiones  pierden  funcionalidad.  Un  gusano  podría  estar 
infectando  la  red,  y  los  sistemas  IDS  ni  enterarse  puesto  que  está  aprovechando  IPsec  para 
no  ser  visto.  También  perderían  funcionalidad  todos  los  sistemas  de  protección  interna 
basados  en  ACL.  Por  ejemplo  los  que  aplican  tos  dispositivos  de  capa  3,  4  y  5  para  la 
comunicación  controlada  entre  VLan  o  la  existencia  de  un  cortafuegos  de  control  interno. 

IPsec,  por  lo  tanto  sí  supone  una  buena  opción,  pero  debe  valorarse  en  qué  medida  y  cómo 
se  aplica  para  que  su  eficacia  no  resulte  contraproducente* 


8.2.-  Redes  Virtuales  Privadas  (VPN).  La  seguridad 
“garantizada” 

La  palabra  VPN,  va  unida  desde  su  origen  a  la  de  seguridad.  Sin  embargo  este  axioma  no 
se  cumple  en  todas  su  facetas.  La  conexión  de  redes  virtuales  privadas,  defínen  eso,  una 
conexión  “segura”  a  través  de  un  medio  inseguro  como  puede  ser  Internet.  Pero  ¿cuál  es 
verdaderamente  la  seguridad  que  ofrecen? 

Todo  depende  de  dos  mecanismos  principales,  el  encapsulamiento  y  la  autenticación. 

En  esencia  el  funcionamiento  sigue  las  normas  defínidas  en  el  punto  anterior,  es  lógico 
cuando  IPsec  es  uno  de  los  mecanismos  más  populares  para  la  implementación  de  VPN. 
Sin  embargo  en  el  caso  de  las  VPN,  antes  casi  que  el  estándar,  se  definieron  previamente  los 
sistemas  de  encapsulamiento  propietarios  de  diferentes  fabricante.  Por  ejemplo  Microsoft 
propuso  PPTP  {Poim  (o  Point  Tunneling  ProtocoJ)  o  Cisco  que  proporcionó  LF2  {Layer 
2  Fonvarding).  Ambos  sistemas  de  VPN  permitían  conexiones  remotas  garantizando  la 
“confídencialidad  de  la  información”  transmitida.  Sin  embargo  el  primero  se  encontraba 
vinculado  a  IP,  mientras  que  el  segundo  no. 

El  proceso  de  autenticación  de  los  sistemas  VPN  tanto  en  PPTP  como  en  L2F  es  realizado 
a  través  del  protocolo  PPP  (Point  ío  Point  Protocot).  Este  protocolo  de  punto  a  punto  fue 
definido  a  través  de  la  RFC  1661  y  data  ya  de!  año  1994.  PPP  admite  múltiples  sistemas 
de  autenticación  que  van  desde  el  más  esencial  PAP  (Password  Authentication  Protocol) 
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donde  las  credenciales  son  enviados  en  texto  plano,  a  los  más  seguros  como  EAP-TLS 
haciendo  uso  del  servicio  PKI  para  el  proceso  de  autenticación. 

Sin  embargo  como  PPTP  y  L2F  eran  considerados  como  propietarios,  la  lETF  {Internet 
Engineering  Task  Forcé)  propuso  L2TP  {Layer  2  Tunneling  Protocoí)  como  sistema 
estándar  para  la  iraplementación  de  túneles.  Como  en  los  casos  anteriores,  L2TP  utilizaba 
PPP  para  el  proceso  de  autenticación. 

Hay  que  tener  en  cuenta  que  ni  PPTP  ni  L2TP  describen  mecanismos  de  cifrado  o 
autenticación,  dejando  la  seguridad  al  protocolo  PPP.  De  cara  a  la  autenticación,  PPP 
depende  por  lo  tanto  de  los  protocolos  de  autenticación  implementables.  Dejar  por  lo  tanto 
la  seguridad  en  manos  de  un  protocolo  del  año  1 994  no  parece  lo  más  óptimo  y  en  esencia  es 
así.  Por  lo  tanto  ante  un  ataque  de  MITM  de  VPN  ¿qué  podría  suceder  con  la  autenticación 
en  manos  de  PPP?  Todo  pasaría  por  lo  tanto  por  depender  del  sistema  de  autenticación. 

Para  escenarios  Microsoft,  los  mecanismos  de  autenticación  admitidos  son:  PAP,  SPAP, 
CHAP,  MS-CHAP,  MS-CHAPv2  y  EAP-TLS.  Excepto  para  el  último,  que  implica  entre 
otras  una  solución  con  infraestructura  PKI,  existen  ataques  conocidos  que  permiten 
recuperar  una  autenticación  de  usuario  y  contraseña,  mediante  la  implementación  de 
diferentes  ataques.  Para  evaluar  dicha  circunstancia  se  va  a  mostrar  un  ataque  sobre  una 
conexión  VPN  de  tipo  PPTP. 

La  conexión  de  PPTP  es  susceptible  al  ataque  de  Man  in  the  Middle  (MITM),  lo  que 
implicaría  el  posible  robo  de  la  información  de  autenticación  que  tuviera  lugar  al  inicio  de 
la  conexión  VPN  ya  que  PPP  no  ofrece  ninguna  garantía  de  cifrado  al  mismo,  la  seguridad 
recae  sobre  el  protocolo  de  autenticación.  Una  contraseña  corta  y  débil  podrá  ser  obtenida 
con  mayor  eficacia  que  una  contraseña  más  larga  y  compleja.  El  mejor  algoritmo  basado 
exclusivamente  en  usuario  y  contraseña  es  MS-CHAPv2,  pero  incluso  este  es  susceptible 
de  ataque  basado  en  diccionario  o  fuerza  bruta. 

MS-CHAPv2  proporciona  autenticación  mutua  con  la  generación  de  claves  de  cifrado 
de  datos  iniciales  más  seguras  para  la  conexión  punto  a  punto  de  Microsoft  (MPPE)  y 
diferentes  claves  de  cifrado  para  los  datos  enviados  y  los  datos  recibidos.  La  autenticación 
se  basa  en  el  método  desafío  respuesta: 

-  El  cliente  solicita  un  desafío  del  servidor. 

-  El  servidor  devuelve  un  desafío  aleatorio  de  16  bytes. 

-  El  cliente  genera  un  número  de  !  6  bytes  aleatorio  denominado  “PeerAuthenticator 
Challenge”. 
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-  El  cliente  genera  una  clave  de  8  bytes  partiendo  del  desafío  recibido  previamente 
del  servidor,  el  generado  por  el  equipo  cliente  y  la  cuenta  de  usuario. 

-  La  respuesta  de  24  bytes,  es  generada  utilizando  la  función  dcl  hash  NT  de 
Windows  y  la  clave  generada  en  el  paso  4. 

-  El  servidor  utiliza  el  hash  de  la  contraseña  del  usuario  almacenada  en  la  base  de 
datos  para  descifrar  la  respuesta.  Si  el  bloque  descifrado  coincide  con  el  desafío,  el 
cliente  es  autenticado. 

-  El  serv'idor  utiliza  la  clave  de  16  bytes  del  cliente  y  el  hash  de  la  contraseña  para 
crear  una  respuesta  del  autenlicador  de  20  bytes. 

-  El  cliente  procesa  una  respuesta  del  autenlicador.  Si  la  respuesta  procesada 
coincide  con  la  respuesta  recibida,  el  servidor  es  autenticado. 


Puesto  que  PPP  no  aporta  un  sistema  de  cifrado  adicional,  el  procedimiento  del  intercambio 
de  claves,  puede  ser  interceptado  para  un  ataque  ofíline.  En  este  sentido  la  aplicación 
ASLHAP  , creada  originalmente  para  atacar  los  procesos  de  autenticación  WiFi  de  Cisco 
con  el  protocolo  LEAP  {Lightweighl  Extensihle  Authentication  Protocol),  fue  modificada 
para  poder  atacar  el  proceso  de  autenticación  MS-CHAP  v2.  Para  el  ejemplo  se  hace  uso  de 
esta  herramienta  Junto  con  la  aplicación  Ettercap  que  se  será  la  utilizada  para  la  realización 
del  ataque  de  hombre  en  medio.  Se  utiliza  para  ello  la  distribución  BackTrack  que  contiene 
ambas  herramientas. 

El  ataque  es  de  tipo  diccionario,  debiendo  crearse  previamente  los  ficheros  de  hashes  e 
índices  dados,  para  un  fichero  de  texto  plano  que  contendrá  las  palabras  a  probar.  Dicho 
diccionario  se  construye  mediante  la  aplicación  genkey  que  viene  conjuntamente  con 
Asleap.  La  siguiente  imagen  muestra  la  generación  de  los  ficheros  de  hashes  e  índices. 
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Como  ya  se  ha  comentado  el  ataque  de  MITM  se  realizará  mediante  Ettercap.  Esta 
aplicación  lleva  un  complemento  que  permite  extraer  el  intercambio  de  desafío  y  respuesta 
de  una  conexión  VPN  PPTP.  El  procedimiento  para  la  realización  del  hombre  en  medio 
sigue  la  secuencia  habitual: 
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-  Habilitar  el  sniffing. 

-  Seleccionar  los  equipos  a  envenenar. 

-  Iniciar  ei  envenenamiento* 


Las  siguientes  3  imágenes  muestran  la  secuencia.  En  primera  instancia  se  habilita  el 
mecanismo  que  habilita  el  modo  promiscuo  en  el  dispositivo. 


^  ^  9tt^rciip  NG-0.7.3  ?  á  x 

£íle 

í^tíons  tl^lp  1 

Bridged  sniffing.,.  Shift+B 

%  Set  pcap  filter...  P 

Fig.  SJ3.-  Preparación  ataque  MITM 


Tras  iniciar  la  captura  y  habiendo  escaneado  la  red  en  busca  de  las  víctimas,  se  realiza  la 
selección  de  estas.  El  ñindamento  es  similar  al  mostrado  en  anteriores  capítulos  con  Caín  y 
Abef  pero  aquí  la  herramienta  permite  una  mayor  flexibilidad  al  real  izar  el  ARP  Poisoning. 
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Fig.  8. 14  -  Selección  de  objetivos  para  el  envenenamiento. 


El  ultimo  paso  consiste  en  habilitar  el  envenenamiento  que  permitirá  reconducir  el  tráfico 
a  través  de  la  máquina  atacante. 
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F\g.  HA  5  -  ARP  Pot-!;onmg 

Antes  del  inicio  de  la  comunicación,  se  comprueba  que  el  único  mecanismo  de  autenticación 
admitido  por  el  cliente  es  MS-CH  AP  v2.  Sería  factible  un  ataque  adicional  en  el  que  tanto 
el  cliente  como  el  ser\ádor  admitieran  MS-CHAP  y  MS-CH  AP  v2,  una  degradación  de 
la  autenticación.  En  el  mismo  aunque  la  negociación  cliente-servidor,  determinará  que 
la  mejor  autenticación  sería  MS-CIIAP  v2  un  atacante  en  medio  podría  renegociar  la 
comunicación  entre  ambos  extremos  para  degradarlo  a  MS-CHAP,  más  vulnerable. 


Fig.  8.16,-  Selección  de  autenticación  MS-CHAP  v2. 
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Al  mismo  tiempo  que  se  produce  el  proceso  de  autenticación  el  atacante  está  recibiendo 
los  dalos  del  proceso  de  autenticación.  La  información  obtenida  por  Ettercap  con  los  datos 
correspondientes  a  la  autenticación  del  usuario  administrator,  se  recogen  en  la  siguiente 
imagen.  Se  ve  la  infomiación  correspondiente  al  desafío  y  la  respuesta  derivada  del  hash 
NT  de  la  contraseña  adrnin.  No  es  utilizado  en  esta  circunstancia  el  hashLan  Manager 
se  presenta  con  ceros. 


[  Py^criptiprt 


j_ IQ  L  Aiidtoigy^  2  : 

dwsJ  ->  i  ^ 

^fTTOtrgtty.** r  WOO«>OOOOOOOOeOOWCO nWSaCflOíeC  »1  WAiftS  If  36«CAÍ»»8»&]  B  iJMff  e70Of  J6€  iítfOTSWi 

Fig.  f  7.-  Captura  Hashes.  Challenge  y  Rt^sponse  del  usuario  Admi  ni  strator. 

Los  hashes  recuperados  se  pueden  utilizar  para  la  realización  del  ataque  de  diccionario,  con 
los  ficheros  creados  previamente  con  Genkeys.  Para  ello  además  del  fichero  de  hash  y  el  de 
índice,  se  proporcionan  los  datos  de  desafío  y  respuesta,  obtenidos  con  Ettercap  tal  y  conio 
pueden  ver  en  la  siguiente  imagen. 
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Fig.  8. 18.- Ataque  contra  la  autenticación  realizado  con  Asleap. 

Evidentemente  la  contraseña  empleada:  admin,  es  lo  sufícientemente  débil  para  que  el 
ataque  sea  eficaz  en  poco  tiempo*  Otros  tipos  de  contraseñas  requerirían  un  esfuerzo 
desmesurado  para  obtenerlas  con  este  método. 

En  un  análisis  pormenorizado  del  protocolo  MS-Chapv2,  se  pudo  comprobar  que  existían 
debilidades  que  hacían  de  él  un  error  para  cualquier  contraseña,  ya  que  en  realidad,  el 
cifrado  3DES  que  se  emplea  no  es  un  cifrado  triple,  sino  3  veces  el  cifrado  de  una  parte  del 
hash  de  la  contraseña,  lo  que  hace  mucho  más  asequible  su  crackeo. 
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En  la  siguiente  imagen  explicativa  creada  por  Moxie  Marlinspike  se  puede  ver  la  negociación 
entre  el  cliente  y  el  servidor,  donde  se  ha  dejado  en  un  sombreado  más  claro  todo  lo  que  se 
envía  por  la  red  -  y  por  tanto  es  capturable  por  un  atacante  -  y  en  un  sombreado  más  oscuro 
lo  que  habría  que  calcular. 

Al  final,  le  Hash  NT  del  usuario  es  un  MD4  de  1 6  byíes  que  se  usa  como  entrada  para  cifrar 
tres  veces  el  Challenge  enviado  desde  el  servidor.  Este  challenge  se  asume  conocido  por  ser 
enviado  por  la  red  y  la  respuesta  que  va  en  Challenge  Responso  también,  ya  que  también  se 
envía  por  la  red,  luego  solo  es  necesario  conocer  cuáles  han  sido  las  claves  de  cifrado  que 
se  han  utilizado  en  los  3  procesos  de  cifi  ado  DES. 


Fig,  8J9.”  Explicación  del  algoritmo  de  MSChapv2 


Como  ic  NTHash  son  16  byles  y  las  claves  DES  son  de  7  bytes,  !o  que  hace  el  algoritmo 
es  utilizar  como  clave  para  el  primer  proceso  de  DES  los  bytes  1  a  7  del  NTHash,  para  el 
segundo  proceso  DES  los  bytes  8  a  14  y  para  el  último  los  bytes  14  y  1 5  más  la  constante 
OüOOO.  Lo  que  simplifica  nnucho  la  tarea  de  cracking  y  obtención  del  NTHash^  ya  que 
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solo  hay  que  hacer  tres  procesos  de  cracking  independientes,  y  el  último  de  ellos  es 
absolutamente  trivial  al  necesitarse  calcular  solo  2  bytes. 

Para  automatizar  todo  este  proceso  se  publicó  la  herramienta  chapcrack  que  busca  en  una 
captura  un  bandshake  MSChap  Vl  y  muestra  las  cadenas  cifradas  del  primer  y  segundo 
proceso  de  cifrado  DES  junto  con  su  challenge  y  descifra  la  última  clave  DES  del  proceso 
“  que  lleva  los  dos  últimos  bytes  del  NTHash. 

Para  terminar  el  proceso,  solo  habría  que  crakear  esas  dos  cadenas  citradas  DES,  que  puede 
hacerse  con  cualquier  herramienta  clásica  de  cracking  DES,  o  directamente  el  servicio 
Cloudcraker  que  permite  crackear  estos  valores  en  menos  de  1  día,  y  por  tanto  tener 
cualquier  password  usada  en  una  VPN-MSChapV2,  sea  la  contrasena  lo  compleja  que  sea. 

L2TP  i  n  icialmente  no  ofreee  mejoras  ostensibles  con  respecto  a  PPTP,  por  lo  que  no  aportaba 
ninguna  solución  adicional  de  segundad  a  las  planteadas  ya  inicialmente.  Consciente  de 
este  hecho,  Microsoft  decidió  en  su  momento  utilizar  L2TP  en  su  variante  con  IPsec,  que 
garantizaba  una  mayor  seguridad  mediante  encapsulamiento,  cifrado  y  firmado  en  capa  3. 
Sin  embargo  PPTP  depositaba  la  seguridad  en  PPP  que  será  el  encargado  de  garantizar  el 
proceso  de  autcntificación. 

IPsec  en  el  modo  túnel  para  uso  en  VPN  ofrece  las  mismas  garantías  de  seguridad  que 
las  vistas  en  el  punto  anterior.  Además  en  una  variante  para  poder  ser  encaminable  a 
través  de  dispositivos  de  protección  perimetra!,  existe  la  posibilidad  de  hacer  uso  de  NAT 
Trasversal  (NAT-T),  permitiendo  el  encapsulamiento  de  un  paquete  TPsec  en  un  datagrama 
UDP  a  través  del  puerto  4500.  Sin  embargo  como  en  el  caso  de  PPTP,  L2F  y  L2TP,  IPsec 
se  encuentra  con  el  problema  de  que  los  puertos  que  utiliza  no  siempre  se  encuentran 
disponibles  para  una  conexión  segura* 

Por  ejemplo,  se  encuentra  en  el  aeropuerto  y  debe  establecer  una  comunicación  muy 
delicada,  disponiendo  únicamente  de  la  conexión  WíFí  que  se  ofrece  en  las  instalaciones. 
¿Cuántas  personas  estarán  compartiendo  ese  medio  y  lo  más  importante  cuántos  serán  de 
fiar?  Tras  lo  escrito  hasta  el  momento,  se  aconseja  cerrar  el  ordenador  y  llegar  a  un  sitio 
más  seguro.  Sin  embargo  si  pudiera  establecerse  una  sesión  VPN  con  la  empresa  o  con  un 
entorno  confiable  como  su  casa,  la  WiFi  no  supondria  ya  un  problema. 

Sin  embargo  la  conexión  que  se  facilita  no  permite  la  conexión  a  puertos  utilizados  por 
las  VPN,  solo  a  los  clásicos  80  y  443.  Claro,  la  gente  no  necesita  otra  cosa*  Esto  que  se  ha 
visto  como  un  problema  en  las  VPN  tradicionales,  tiene  ya  su  solución,  garantizando  la 
seguridad  de  la  comunicación*  Hacer  uso  de  conexiones  SSL  a  través  de  puerto  443  para 
el  establecimiento  del  túnel.  Microsoft  por  ejemplo  i mpl ementa  desde  Windows  Vista  y 
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Windows  2008  el  cliente  y  servicio  de  VPN  SSTP  {Secure  Socket  Tunneling  Protocoi). 
Ofrece  garantías  de  seguridad  con  autenticación  doble: 

-  Autenticación  para  el  túnel  basado  en  certificado  (conexión  tipo  SSL). 

-  Autenticación  de  usuario  con  múltiples  sistemas:  NTLMv2,  Kerberos,  EAP-TLS. 


Frente  a  los  ataques  de  MFTM  de  tipo  HTTPS  que  ya  se  vieron.  En  esta  circunstancia 
ante  un  mínimo  problema  con  el  certificado  o  si  no  existe  acceso  a  la  lista  de  certificados 
revocados,  la  comunicación  no  se  establecerá. 

Estas  implementaciones  se  están  extendiendo  rápidamente  y  sustituyen  a  las  más  clásicas 
pero  menos  funcionales  a  día  de  hoy.  Cisco  por  ejemplo  implementa  CBN  Anyconnect 
como  solución  SSL  alternativa  a  su  L2F  o  al  estándar  de  íPsec. 


8.3.-  Protección  de  acceso  a  redes 

Las  redes  a  día  de  hoy  con  el  volumen  de  máquinas,  ofrecen  una  ocultación  casi  perfecta 
para  un  atacante.  Un  administrador  de  red  por  lo  general,  desconoce  quién  se  encuentra 
en  la  red  y  en  qué  condiciones.  Un  consultor  que  entra  en  una  empresa  para  realizar  una 
actividad  podría  llegar  de  hacer  alguna  acción  en  la  competencia  y...  sí,  todo  el  mundo  es 
bueno,  pero  también  puede  tener  un  precio. 

Se  le  podía  indicar  al  consultor  que  no  puede  utilizar  su  equipo  y  que  en  su  lugar  debe 
utilizar  el  equipo  que  le  proporciona  ía  organización.  Sin  embargo  ¿quién  le  va  a  controlar 
posteriormente?.  Qué  aplicaciones  ejecutará  y  qué  liará,  suponen  un  misterio  para  muchas 
organizaciones.  Con  redes  tan  grandes  para  controlar,  la  monitorización  a  día  de  hoy  supone 
también  un  desafío. 

También  existe  el  problema  de  los  equipos  corporativos  misteriosos.  El  típico  equipo  al 
que  le  aparece  una  aplicación  “sospechosa’’  o  que  no  tiene  antivirus  o  que  aparecen  más 
administradores  locales  de  los  debidos.  Quién  tiene  la  capacidad  para  controlar  lo  que  pasa 
en  todos  los  sistemas  de  la  red.  Aunque  existen  sistemas  de  control  de  la  seguridad,  suelen 
ser  costosos  económicamente  y  requieren  un  alto  tiempo  de  administración. 


Para  paliar  este  problema  desde  hace  tiempo  están  surgiendo  diferentes  tecnologías  que 
tratan  de  controlar  lo  que  pasa  en  la  red  desde  un  punto  de  vista  simple.  Si  quieres  estar 
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debes  cumplir  una  serie  de  reglas,  si  no  las  cumples  estás  ñiera  o  entras  en  cuarentena.  De 
todas  quizás  las  más  conocidas  pueden  ser  la  de  Microsoft  {NÁP  NetWork  Access  Protection) 
y  la  de  Cisco  (NAC  Network  Admission  Control). 

La  idea  base  es  la  siguiente:  un  sistema  centra!  se  encarga  de  recibir  las  peticiones  de 
acceso  a  las  redes  y  tendrá  que  ocuparse  de  deteraiinar,  en  base  a  unas  condiciones  de 
seguridad  y  sanidad,  el  estado  de  salud  o  seguridad  de  todas  y  cada  una  de  las  máquinas 
que  desean  entrar  dentro  de  la  red 

Dicho  acceso  se  encuentra  mediatizado  a  través  de  un  dispositivo  o  seivácio  de  red  que 
facultará  el  acceso  al  cliente  y  que  se  pondrá  en  contacto  con  el  servidor  de  gestión  central. 
Este  dispositivo  aceptará  las  peticiones  de  tos  clientes  y  solicitarán  e!  estado  de  seguridad  a 
los  mismos  a  través  de  unos  agentes.  Éstos,  instalados  en  las  máquinas  clientes  recuperarán 
la  información  y  la  remitirán  al  servidor  vía  el  sistema  de  red. 

En  unas  pocas  frases  se  ha  descrito  un  procedimiento  evidentemente  muy  complejo.  En 
este  punto  lo  esencial  es  determinar  por  dónde  se  controla  el  acceso  a  la  red  y  aquí  existen 
diversas  alternativas.  La  más  lógica  implica  directamente  a  la  electrónica  de  red  por  ejemplo 
los  Switch  de  capa  2  o  los  puntos  de  acceso  inalámbrico.  Sin  embargo  sistemas  de  Terminal, 
VPN  o  DHCP  pueden  ser  también  mecanismos  de  acceso  que  permitirían  el  control  de  la 
red. 

En  este  sentido  las  soluciones  de  control  de  acceso  a  redes  ofrecen  múltiples  escenarios  y 
soluciones.  En  una  red  cableada  el  control  mediante  los  Switch^  permitiría  en  función  del 
estado  de  seguridad  de  los  puestos  de  trabajo  que  estos  se  encontrarán  en  una  VLAN  o  en 
otra. 

Si  por  ejemplo  se  detecta  que  los  equipos  no  tienen  anti virus,  estos  pasarían  a  una  red  de 
cuarentena  donde  tendrían  a  su  alcance  los  elementos  para  poder  dar  una  solución  a  esto: 
servicios  de  remedio. 

Una  vez  que  el  anti  virus  en  la  máquina  ya  se  encontrará  instalado  y  en  con  una  estado  lo 
suficientemente  actualizado  como  para  darse  por  seguro,  podría  pasar  de  forma  automática 
a  la  red  de  propósito  general. 

Si  un  equipo  no  contara  con  el  agente  correspondiente  para  facilitar  la  información  que  se  le 
requiere,  podría  también  conlar  en  la  red  de  cuarentena  con  los  servicios  básicos  necesarios 
para  mantener  el  máximo  nivel  de  acceso  que  se  pueda  dar  a  un  equipo  de  sus  condiciones, 
corno  por  ejemplo  dejarlo  en  una  red  de  acceso  de  cortesía  a  Internet  independiente,  para  la 
descarga  e  instalación  manual  de  todo  lo  necesario  para  cumplir  la  política  de  salud. 
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Así,  si  una  máquina  de  alguien  ajeno  a  la  organización  y  violando  las  normas  establecidas, 
se  conectara  a  la  red  cableada  pasaría  a  estar  en  un  segmento  donde  la  infomiación  existente 
no  es  crítica  y  en  caso  de  realizar  ataques  el  impacto  sería  muy  bajo. 


Fig.  8.20.-  Método  de  eonexíón  de  red. 


Podría  también  dictaminarse  la  posibilidad  y  en  función  el  tipo  de  máquina  entrar  en  una 
VLAN  u  otra.  De  esta  forma  las  arquitecturas  de  comunicación  serían  más  flexibles  que 
las  planteadas  actualmente.  Un  equipo  se  mantendría  en  el  segmento  en  el  que  se  encuentra 
habitual  mente  por  lo  que  es,  y  no  como  se  realiza  actualmente  en  función  de  donde  se 
conecta. 

En  modo  similar  se  podrían  darlas  condiciones  para  el  acceso  a  la  red  WiFi  de  la  organización. 
Los  clientes  no  solo  deberían  superar  los  chequeos  de  autenticación  requeridos,  sino 
también  los  de  sn  estado  de  salud  Si  estos  no  son  los  adecuados  pasarían  a  un  segmento  no 
conectado  a  la  red  común  de  la  organización.  Si  por  algún  motivo  existiese  una  intrusión 
en  la  red  inalámbrica  el  atacante  pasaría  a  la  red  de  cuarentena  o  sería  rechazado  por 
incumplimiento  de  medidas:  estado  de  salud,  agente,  autenticacióii,  necesidad  de  tener  una 
aplicación  específica,  que  la  tarjeta  de  red  no  se  encuentre  en  modo  promiscuo,  situación 
del  grupo  de  administradores  locales,  cerlificado  concreto,  etcétera. 


La  imagen  siguiente  muestra  los  validadores  base  gestionados  por  el  servidor  de  directivas 
de  red  de  Microsoft.  Estas  opciones  pueden  ser  ampliadas  en  base  a  múltiples  criterios.  Otros 
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fabricantes  amplían  estas  condiciones  de  NAP,  permitiendo  validar  más  funcionalidades 
tales  como  versiones  concretas  de  antivirus  o  productos  de  seguridad  concretos  que  se 
suman  a  las  más  específicas. 


Fig.  82  ] .-  Vatidadoreti  base  de  cumplimiento  NAP. 


También  en  el  acceso  a  servicios  como  los  correspondientes  a  sistemas  Terminal  o  VPN 
serían  propicios  los  controles  de  acceso  a  la  red.  Cómo  en  la  red  inalámbrica,  sumado  a 
quién  eres,  proporciona  una  seguridad  mayor  que  la  que  se  ofrecen  actualmente.  Máxime 
en  servicios  como  estos  donde  pueden  convivir  ciementos  externos  a  la  organización  y 
expuestos  a  ataques  por  ser  públicos. 

Un  caso  especial  lo  refiere  la  impicmentación  sobre  servicios  de  red  como  el  DHCP.  Aunque 
inicialmente  se  plantee  como  una  medida  eficaz,  (te  doy  IP  si  muestras  una  seguridad 
adecuada),  no  es  capaz  de  plantear  una  estrategia  de  seguridad  global.  EL  atacante  podría 
ponerse  una  dirección  IP  de  forma  manual,  lo  que  provocaría  que  la  medida  fuera  ineficaz. 
Esta  última,  aunque  por  sí  sola  no  es  una  medida  totalmente  eficaz,  si  puede  plantearse  en 
una  estrategia  combinada. 
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Además  del  lógico  control  de  acceso,  la  solución  del  mismo  a  redes  permite  que  el 
administrador  tenga  conciencia  del  estado  general  en  el  que  se  encuentran  las  estaciones 
de  trabajo  o  los  servidores.  Por  ejemplo  cuáles  se  encuentran  sin  solución  cmtimahvare  o 
desactuai izados.  Permite  así  la  cuantiflcación  del  riesgo  y  que  puedan  darse  respuestas  ante 
situaciones  de  gravedad.  En  esta  circunstancia  la  seguridad  ya  no  es  un  mero  accesorio, 
sino  una  exigencia. 

Los  clientes  por  su  parte  deberán  contar  habitual  mente  con  un  agente  (no  siempre  es  así, 
puesto  que  algunas  soluciones  existentes  en  el  mercado  pueden  trabajar  sin  agente)  que 
será  el  encargado  de  emitir  la  información  que  llegará  al  servidor  de  directivas  de  red. 

Este  agente  también  enviará  los  cambios  que  permitan,  una  vez  que  ya  se  hayan  corregido 
todos  los  problemas,  que  se  puedan  revaluar  las  condiciones  de  salud  para  poder  salir  de  la 
red  de  cuarentena. 


Fig.  Cliente  de  cumplimiento  NAR 


En  el  sentido  estricto  de  la  expresión,  las  soluciones  de  control  de  acceso  a  redes  no  evitan 
de  forma  directa  los  ataques  de  redes  de  datos  como  el  ampliamente  explicado  esquema 
del  hombre  en  medio.  Sin  embargo,  este  tipo  de  medidas  de  seguridad  proporcionan  un 
elemento  fundamental  para  que  la  red  se  encuentre  más  saneada  y  más  protegida,  pudiendo 
conocer  quién  entra  y  quién  sale  de  la  red,  y  lo  que  es  aún  mucho  más  importante,  en  qué 
condiciones  de  salud.  Permite  por  lo  tanto  que  se  puedan  controlar  las  reglas  deí  juego  y  así 
descartar  que  un  elemento  externo,  por  ejemplo  un  portátil  ajeno  a  la  organización,  pueda 
convivir  con  información  sensible  de  esta. 
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8.4.-  DHCP  Snooping 

Si  en  el  caso  anterior  la  red  no  aportaba  una  solución  directa  contra  los  ataques  de  hombre 
en  medio,  la  siguiente  contramedida  va  fundamentalmente  enfocada  a  ello.  Tal  y  como 
se  ha  visto  en  las  páginas  previas  uno  de  los  elementos  comunes  en  los  ataques  vistos, 
consiste  en  reconducir  el  tráfico  a  través  de  la  máquina  atacante.  Para  ello  el  más  efectivo 
consiste  en  emplear  la  técnica  de  ARP  Poisoning.  Puesto  que  todo  el  tráfico  pasa  a  través 
de  los  Switch,  ¿por  qué  no  bloquear  el  ataque  directamente  en  los  mismos?.  Para  ello  lo  más 
lógico  es  plantear  un  mecanismo  de  aprendizaje  donde  los  dispositivos  autoricen  el  tráfico 
válido  y  bloqueen  el  que  no  lo  es.  Para  lograrlo  es  necesario  que  el  dispositivo  sea  capaz 
de  interpretar  las  capas  2  y  3  de  la  comunicación.  Almacenarán  en  su  tabla  las  peticiones 
correctas  de  IP  vinculadas  a  las  MAC  y  rechazará  cualquier  tráfico  que  no  se  corresponda 
con  los  pares  MAC  e  IP  almacenados. 

La  cuestión  critica  deriva  en  cómo  se  construye  la  tabla  de  MAC  para  que  la  información 
sea  veraz  y  no  pueda  ser  falseada.  La  solución  fue  a  través  de  las  peticiones  y  respuestas 
de  DHCP  {DHCPOFFER,  DHCPACK,  DHCPNAKy  DHCPLEASEQUERY).  Aquí  existen 
dos  alternativas  que  pueden  utilizarse  en  las  redes  para  garantizar  la  protección  contra  el 
envenenamiento  ARP, 

En  la  primera  el  Switch  o  conjunto  de  ellos  tiene  autorizado  solamente  detenninados  puertos 
para  hacer  una  oferta  correcta  de  direcciones  ÍP.  Así  se  anula  también  la  posibilidad  de  que 
servidores  DHCP  falsos  puedan  estar  dando  información  que  suponga  una  suplantación  a 
nivel  de  IP.  Solo  serán  procesadas  y  permitidas  aquellas  peticiones  y  respuestas  correctas 
de  DHCP,  de  tal  forma  que  circunstancias  anómalas  serán  descartadas  por  la  electrónica  de 
red.  Por  lo  tanto  una  petición  y  oferta  de  IP  deberá  seguir  las  reglas  convencionales. 


Router#  configure  tefmnal 

£nter  configuration  conuBajids,  one  per  line,  End  with  CííTL/Z. 

Router  (CQuf  ig)  #  ip  dhcp  snooping 

Rourerfeonfig)  #  do  show  ip  dhqp  snooping  f  incltiíle  Switch 
Switch  DHCP  snooping  i  a  enabled 
Router [conf ig) # 

Fig,  8.23.-  üabili1:arD//CPL'ffífjíj/Jí>í^, 

Toda  petición  y  respuesta  ofrecida  para  todos  los  puertos  excepto  los  excluidos,  serán 
interpretadas  e  introducidas  en  las  tablas  correspondientes.  Si  una  máquina  conectada  a 
un  puerto  controlado  dispusiera  una  IP  manualmente,  sus  tramas  serían  rechazadas  por  no 
encontrarse  en  las  tablas  que  autorizan  la  conectividad. 
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Si  un  atacante  iniciara  un  ataque  de  ARP  Poisoníng^  las  tramas  ARP  Reply  falsas,  serían 
rechazadas  puesto  que  no  corresponderían  con  los  pares  de  direcciones  IP  y  direcciones 
MAC  almacenados. 

El  segundo  mecanismo  ofrece  una  solución  similar,  aunque  en  este  caso  las  peticiones 
de  DHCP  son  atendidas  directamente  por  la  electrónica  de  red.  Los  Switch  actúan  como 
Agentes  Rely  de  DHCP,  de  tal  forma  que  escuchan  las  peticiones  de  direcciones  IP  que  se 
producen.  Estos  las  hacen  suyas  y  realizan  la  solicitud  en  su  nombre  a  los  servidores  DHCP 
que  hayan  podido  especificarse.  Con  la  respuesta  DHCP  se  realiza  la  entrega  al  cliente, 
anotando  la  información  correspondiente  a  la  dirección  IP  y  física. 

Sin  embargo  aunque  el  sistema  de  DHCP  Snooping  es  muy  interesante  puede  presentar 
ciertas  limitaciones.  En  primera  instancia  tener  una  electrónica  de  red  válida.  Las  capacidades 
base  del  sistema  más  la  de  la  electrónica  de  red  será  la  que  detennme  la  capacidad  máxima 
de  información  que  puede  almacenarse  en  la  tabla. 

Por  ejemplo  en  los  dispositivos  Cisco  revisiones  de  IOS  {intenietwork  Operaiíng  System) 
anteriores  a  la  12.2(18)SXF5  admiten  hasta  un  máximo  de  512  elementos  en  la  tabla.  Sin 
embargo  revisiones  de  IOS  posteriores  permiten  hasta  8000  entradas. 

DHCP  Snooping  ofrece  una  solución  de  protección  contra  ataques  ARP  Spoofing,  sin 
embargo  no  ofrecen  actualmente  una  solución  para  los  ataques  de  hombre  en  medio  que  se 
pueden  realizar  en  IPv6.  La  adaptación  de  la  electrónica  de  red  está  limitada  a  la  versión 
4  de  IP,  Fallos  en  la  funcionalidad  de  los  dispositivos  podría  suponer  que  los  sistemas 
quedaran  incomunicados. 


8.5.-  Prevención  de  ataques  ARP  Poisoníng 

Tal  y  como  se  ha  comentado  la  prevención  del  ataque  de  MITM  se  puede  dar  en  la 
electrónica  de  red.  Pero  eso  implica  un  coste  que  muchas  organizaciones  no  pueden 
sufragar.  Sin  embargo  existe  un  mecanismo  que  aunque  más  manual,  puede  prevenir  contra 
el  envenenamiento  de  ARP. 

Puesto  que  el  ataque  fundamental  de  hombre  en  medio  se  basa  en  facilitar  una  información 
falseada  de  dirección  IP  y  MAC,  ¿qué  pasaría  si  el  sistema  no  aceptara  la  información 
falsa?  Si  se  introduce  manualmente,  no  podrá  aprender  información  falsa  aunque  se  le 
facilite  por  parte  de  un  atacante. 
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Fig,  S;24."  Entradas  estáticas  cii  la  tabla  ARP. 


Las  entradas  estáticas  evitarán  que  los  equipos  puedan  ser  atacados  mediante  ARP 
Poisoning^  sin  embargo  presenta  también  su  problemática.  Es  difícil  mantener  entradas 
estáticas  en  un  escenario  de  concesión  de  direcciones  IP  dinámicas.  Debería  por  lo  tanto 
ceñirse  la  protección  a  las  direcciones  IP  y  servicios  más  significativos  que  suelen  ser  fijos: 
ser\d dores,  direcciones  significativas  como  las  web  de  la  organización  o  la  electrónica  de 
red. 

Ante  posibles  cambios  de  tarjetas  de  red  o  entrada  de  nuevos  servicios,  deberán  aplicarse 
los  cambios  a  los  sistemas  para  que  sean  efectivos.  Por  ejemplo  una  forma  de  aplicar 
las  entradas  es  mediante  Scripts  de  inicio  de  sesión  de  equipo.  Sin  embargo  en  muchas 
ocasiones  los  equipos  no  son  reiniciados  y  por  lo  tanto  los  cambios  podrían  no  ser  efectivos, 
con  lo  que  podría  condicionar  que  determinados  clientes  no  pudieran  llegar  a  determinados 
sistemas 

Puesto  que  la  información  es  almacenada  localmente,  pudiera  ser  que  si  se  aplicara  también 
a  dispositivos  portátiles,  estos  cuando  sal  ieran  de  la  red  tuvieran  problemas  de  comunicación 
si  coincidieran  las  direcciones  ÍP  almacenadas,  con  otras  existentes  en  la  otra  red  en  la  que 
se  conectaran.  El  uso  de  IP  de  tipo  privadas  y  la  confluencia  en  el  uso  de  las  mismas  hacen 
que  la  coincidencia  sea  factible. 

Manejar  por  lo  tanto  entradas  estáticas  es  una  solución  económica  y  efectiva  contra  ataques 
de  ARP  Poisoning,  sin  embargo  puede  incurrir  en  problemáticas  de  administración.  Los 
administradores  de  red  y  sistemas,  cuentan  con  un  punto  de  fallo  más  a  tener  en  cuenta  si 
se  dan  problemas  de  comunicación. 
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8.6.-  Detección  de  ataques  de  ARP  Poisoning 

Algo  menos  restrictivo  que  en  el  caso  anterior,  pero  que  puede  hacer  saltar  las  alarmas 
ante  un  potencial  ataque  de  ARP  Poisoning  son  las  aplicaciones  que  detectan  anomalías  en 
las  peticiones  y  respuestas  ARP  cotejadas  con  las  que  se  encuentran  en  una  tabla  de  tipo 
local.  Este  mecanismo  debe  ser  considerado  como  preventivo,  puesto  que  no  va  impedir  el 
ataque,  sino  solo  advertir  del  mismo. 

Se  muestra  a  eontinuación  la  funcionalidad  de  la  aplicación  Marmita  para  la  detección  de 
este  tipo  de  ataques. 

En  esta  primera  imagen  se  muestra  la  infonnación  facilitada  por  la  aplicación 
Marmita  indicando  que  el  sistema  no  se  ha  visto  afectado  por  ataques  de  tipo  ARP 
Poisoning. 


Fig,  8,25.-  Sisléma  sin  ataques  ARP  Foisúning. 

Cuando  el  entorno  de  conexión  en  el  que  se  encuentre  el  equipo  detecte  una  situación 
anómala,  entonces  Marmita  generará  una  alerta  de  seguridad,  informando  que  un  paquete  de 
red  que  intenta  hacer  un  ataque  man  in  the  middle  para  atacar  la  máquina  ha  sido  detectado. 

En  la  siguiente  imagen  se  puede  ver  que  la  misma  máquina  ahora  se  encuentra  sufriendo  un 
ataque  de  hombre  en  medio  mediante  envenenamiento  ARP. 
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La  aplicación  advierte  de  este  hecho  con  un  popup  si  está  oculto  el  interíáz  gráfico. 


Fig.  8.26.-  Sifitema  atacado. 

Tal  y  como  se  puede  advertir  en  la  siguiente  imagen  la  tabla  local  muestra  el  mismo 
dircccionainiento  físico  para  la  dirección  IP  192. 168.1 .1  (Router)y  la  192.168.1 . 16  (sistema 
atacante). 
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Fig,  8.27,-  Tabla  local  ARP 


208 


Ataques  en  redes  de  datos  lPv4  e  IPv6 


Para  que  la  detección  sea  efectiva,  es  necesario  que  el  ataque  llegue  al  sistema  que  está 
encargándose  de  la  monitorización.  Es  por  lo  tanto  el  azar  el  que  puede  llegar  a  determinar 
la  existencia  del  ataque  y  eso  en  seguridad  no  es  preceptivo.  Por  lo  tanto  en  caso  de  que  esta 
íuncionalidad  fuera  un  mecanismo  de  seguridad  a  tener  en  cuenta  debería  disponerse  de 
un  sistema  que  pudiera  recoger  el  tráfico  y  analizarlo  para  detectar  los  potenciales  ataques, 

Detenninadas  aplicaciones  como  Marmita  presentan  un  comportamiento  preventivo.  Para 
ello  mantienen  una  base  de  datos  virtual  con  la  infomiación  coTTespondiente  a  cómo  era  la 
tabla  ARP  original  cuando  el  sistema  inició  su  sesión.  Tai  y  como  puede  verse  la  dirección 
IP  dei  Router  mantiene  una  dirección  física  diferente  de  la  imagen  anterior,  cuando  el 
ataque  se  encontraba  en  proceso. 


Fig.  ÍÍ.2K.-  Tabla  ARP  Virtual. 

Si  el  parámetro  de  solución  automática  está  activo,  la  aplicación  volcará  el  resultado 
de  la  Tabla  ARP  Virtual  en  la  de  la  caché  ARP  local,  ante  la  detección  del  alaque  por 
envenenamiento. 


Fig.  8,29  -  Resolución  automática. 
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Existen  otras  aplicaciones  en  el  mercado  tanto  en  entornos  Microsoft  (XARP)  o  en  el 
mundo  Linux  (ArpON)  que  pueden  ofrecer  funcionalidades  similares. 


Fig.  8.3Ü.-  Deitíctíón  de  ataque  con  XARP. 


Los  sistemas  de  detección  de  intrusiones  suelen  contar  también  con  mecanismos  para  la 
detección  de  este  tipo  de  ataques.  Un  IDS  puede  interpretar  múltiples  tipos  de  ataques, 
incluidos  los  correspondientes  a  los  de  redes  de  datos.  El  objetivo  fundamental  es  concentrar 
en  ellos  e!  tráfico  circulante. 

Los  puertos  analizadores  que  presentan  los  Switch^  son  utilizados  precisamente  por  sus 
características  para  los  sistemas  de  protección.  Los  sistemas  IDS  cuentan  habíLualmente  con 
dos  tarjetas  de  red,  uno  el  que  corresponde  al  de  administración  y  otro  en  modo  promiscuo 
para  la  recogida  y  análisis  de  tráfico.  Este  adaptador  será  el  que  quede  conectado  al  sistema 
de  consolidación  de  tráfico.  En  el  caso  de  una  gran  red,  será  necesario  disponer  de  un 
sistema  de  análisis  distribuido. 
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Para  ello  pueden  disponerse  de  sondas  de  red  que  recojan  el  tráfico  y  centralicen  la 
infomiación  de  alertas  detectadas  en  un  único  repositorio  de  información  centralizada.  No 
obstante  el  uso  de  una  aplicación  como  Marmita  podría  también  llegar  a  ejecutarse  en  un 
sistema  conectado  a  un  puerto  donde  se  redirige  todo  el  tráfico  de  la  red,  de  igual  forma 
que  se  realiza  con  un  ÍDS. 


Fíg,  831 IDS. 


Actualmente  también  muchos  sistemas  Firewalf  cuentan  con  sistemas  de  detección  o 
de  prevención  frente  a  intrusiones.  Estos  son  capaces  de  detectar  determinados  tipos  de 
ataques  que  pudieran  estar  dándose  en  la  red  controlada  por  el  Firewall.  La  evolución  de 
los  mismos  es  una  constante  y  han  sido  adaptados  para  dar  solución  a  las  problemáticas 
posibles.  Hay  un  claro  ejemplo  con  los  módulos  WAF  (  Web  Application  Firewall)  que 
ofrecen  funcionalidades  adicionales  que  hasta  fechas  actuales  no  existían. 


Poco  a  poco  también  los  sistemas  IDS  e  IPS  han  sido  incorporados  a  las  soluciones  de 
cortafuegos.  Estos  avances  permiten  que  los  firewalls  puedan  ser  fiincionales  más  allá 
de  los  sistemas  de  protección  perimelral  en  los  que  suelen  ser  dispuestos.  La  seguridad 
funcional  que  aportan  estas  nuevas  funcionalidades  ofrecen  otra  dimensión  a  la  protección 
frente  a  los  ataques  en  las  redes  de  datos.  Las  funciones  de  IDS  deben  ser  consideradas 
como  reactivas  y  requieren  que  el  administrador  sea  alertado  y  pueda  dar  una  respuesta 
frente  a  la  incidencia. 
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Los  sistemas  IPS  son  proactivos,  pero  en  el  caso  de  que  se  den  falsos  positivos,  podrían 
llegar  a  denegar  tráfico  legítimo.  Aunque  las  incidencias,  motivadas  por  la  depuración,  son 
cada  día  menores,  se  convierte  nuevamente  en  un  factor  más  a  tener  en  cuenta  en  caso  de 
problemas  de  comunicación. 

Cada  solución  mostrada  supone  una  traba  más  en  la  posibilidad  de  que  un  atacante  logre 
su  objetivo  en  la  red  En  ocasiones  solo  la  conjunción  de  varias  de  ellas  hará  efectivo  que 
el  problema  deje  de  serlo.  Las  empresas  deberán  tener  en  cuenta  con  qué  mecanismos 
cuentan,  cuál  es  la  inversión  que  pueden  llegar  a  realizar  y  qué  nivel  de  seguridad  quieren 
llegar  a  alcanzar  finalmente. 
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Capítulo  IX 

Segmentación  de  una  red 


El  tópico  divide  y  vencerás  que  se  aplica  normalmente  a  las  confrontaciones  que  tiene  el  ser 
humano,  puede  ser  perfectamente  trasladado  a  los  aspectos  tecnológicos. 

En  el  caso  de  las  redes  constituye  un  elemento  fundamental  en  dos  aspectos: 

-  Funcionalidad.  Más  sistemas  en  una  red  suponen  una  carga  mayor  en  la 
capacidad  de  la  misma,  pudiendo  llegar  en  determinadas  circunstancias  a  ser  un 
lastre  significativo. 

-  Seguridad.  Mezclar  diferentes  cntomos  puede  dar  pie  a  un  mayor  factor  de 
amenaza  y  la  imposibilidad  de  atajarlo  o  ni  tan  siquiera  llegar  a  conocer  lo  que  está 
pasando. 


Desgraciadamente  cuando  muchas  organizaciones  plantean  la  segmentación  de  la  red,  lo 
hacen  fundamentalmente  siguiendo  el  primero  de  los  argumentos  expuestos.  Este  hecho 
no  obstante  condiciona  en  muchos  casos  que  de  rebote  se  aplique  inconscientemente  el 
segundo  de  los  elementos  planteados. 

Cuando  alguien  decide  segmentar  una  red  en  base  a  la  seguridad  debe  determinar  qué 
objetivo  se  persigue  con  ello.  Varios  son  los  factores  fundamentales  y  se  enuncian  a 
continuación: 

-  Dividir  por  funcionalidad  e  intereses  las  características  de  los  usuarios  de  una 
organización. 

-  Separar  servicios  y  usuarios  dentro  de  una  misma  red. 

-  Controlar  el  tráfico  que  se  diera  entre  las  diferentes  redes. 

-  Impedir  que  determinados  tipos  de  ataques  puedan  afectar  a  o  entre  determinados 
entornos  de  la  organización. 
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Supóngase  un  ejemplo  en  un  virus  tipo  gusano  que  se  propaga  por  la  red.  Sin  la  debida 
segmentación  y  protección,  este  podría  llegar  a  alcanzar  a  todos  ios  sistemas  de  la 
organización.  Sin  embargo  con  la  debida  protección  la  infección  podría  llegar  a  localizarse 
y  aislarse  generando  un  estado  de  cuarentena  en  la  red.  Para  que  esto  resulte  efectivo  no 
vale  simplemente  con  el  propósito  de  segmentar  la  red. 

Si  la  red  ba  sido  segmentada  con  objeto  de  que  sea  más  funcional,  como  por  ejemplo  se 
ha  reducido  el  tráfico  de  broadcast,  seguramente  no  se  habrán  planificado  métodos  de 
control  y  prevención  de  tráfico  entre  zonas  por  seguridad.  De  esta  forma  al  final  resulta 
que  todas  las  subredes  físicas  de  la  organización  quedarán  conectadas  y  a  un  gusano  tipo 
convencional  no  le  resultará  nada  complicado  ir  saltando  de  una  a  otra.  Sin  embargo  en 
el  caso  de  que  se  apliquen  mecanismo  de  control  como  ACL  o  sistema  de  detección  de 
intrusiones,  la  organización  contará  con  un  sistema  de  protección  reactivo  para  dar  una 
respuesta  rápida  ante  una  incidencia. 

La  seguridad  tal  y  como  se  ha  estado  transmitiendo  a  lo  largo  del  libro  debe  ser  considerada 
desde  un  punto  de  vista  global,  aplicando  múltiples  mecanismos  para  garantizar  su 
cumplimiento.  Esto  no  es  óbice  para  que  el  propio  proceso  de  segmentación  mitigue 
detenuinados  ataques  que  han  sido  comentados  en  las  páginas  de  este  libro.  Por  ejemplo  el 
solo  hecho  de  segmentar  una  red  limita  la  posibilidad  del  ataque  áe  ARP Poisoning,  aunque 
no  se  aplique  ninguna  medida  adicional. 

Hay  que  tener  en  cuenta  como  elemento  fundamental  que  el  ataque  de  ARP  Poisoning  es 
un  ataque  de  capa  2,  donde  el  objetivo  es  la  alteración  de  las  direcciones  físicas  aprendidas 
por  las  máquinas.  Esto  implica  que  en  el  momento  en  el  que  se  produce  el  cambio  de  capa 
de  red  (subred  IP  diferente)  el  ataque  ya  no  resulta  factible.  No  es  posible  para  un  atacante 
realizar  un  envenenamiento  ARP  de  dos  sistemas  que  se  encuentran  fuera  de  su  segmento 
lógico. 

No  obstante  hay  que  tener  en  cuenta  como  ya  se  mencionó  en  páginas  previas  que  la 
segmentación  a  nivel  lógico  debe  llevar  implícita  la  segmentación  física  de  la  red.  Algunas 
organizaciones  basan  su  “segmentación”  en  la  asignación  de  diferentes  direcciones  IP  a  los 
equipos  de  la  organización,  pero  manteniendo  un  único  espacio  físico  de  convivencia.  Si 
un  atacante  escuchando  en  la  red  fuera  consciente  de  la  existencia  de  tráfico  de  múltiples 
segmentos  lógicos,  podría  ir  pasando  de  unos  a  otros  con  el  simple  cambio  de  IP. 

Este  hecho  sucede  en  ocasiones  cuando  un  determinado  departamento  para  su  uso, 
implementa  una  conexión  ADSL  para  la  salida  hacia  Internet.  El  dispositivo  de  enrutamiento 
lo  conectan  a  la  red  y  lo  “camuflan”  mediante  un  espacio  de  direcciones  IP  diferentes  del 
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utilizado  por  la  organización.  Si  algiin  atacante  lo  llegara  a  detectar  se  le  estaría  facilitando 
además  un  mecanismo  para  poder  salir  a  Internet  sin  el  control  exhaustivo  que  podría 
aportar  el  sistema  de  protección  perimetral  que  tanto  coste  ha  llevado  realizar.  Es  más, 
en  esa  circunstancia  el  daño  podría  ser  mayor,  puesto  que  el  atacante  podría  generar  a 
través  de  una  conexión  reversa,  una  comunicación  a  través  de  esa  red  no  controlada”  para 
entrar  cuando  quisiera  en  la  red  interna.  Se  convertiría  por  lo  tanto  en  una  puerta  trasera 
significativa. 

La  seguridad  en  este  sentido  no  hay  que  tomársela  a  la  ligera  y  plantear  una  buena  estrategia 
para  la  segregación  de  las  redes. 


9.1,-  VLAN:  protección  y  ataques 

Cuando  se  habla  de  segmentar  redes  el  primer  impulso  pasa  por  identillcarlo  con  las  redes 
virtuales  privadas  de  red  de  área  local  o  VLAN.  Sin  embargo  en  muchas  circunstancias 
se  puede  conseguir  el  mismo  efecto  sin  necesidad  de  dicha  tecnología.  Por  ejemplo  unos 
Swilch  donde  están  conectados  los  equipos  y  comunicados  entre  ellos  a  nivel  de  capa  3  por 
ejemplo  mediante  un  Router.  La  aplicación  de  ACL  permitiría  controlar  el  tipo  de  tráfico 
que  puede  intercambiarse  entre  las  diferentes  subredes. 

Evidentemente  aunque  la  solución  puede  resultar  efectiva,  hay  que  tener  en  cuenta  que 
presenta  una  serie  de  trabas: 

-  No  es  flexible.  Los  sistemas  se  encuentran  limitados  por  la  propia  situación  de  la 
electrónica  de  red.  En  muchas  ocasiones  surgen  problemas  en  puertos  o  en  dispositivos 
lo  que  implica  cambios.  Salvo  que  se  sea  muy  ordenado,  las  problemáticas  que 
pueden  sucedcrse  en  la  red,  podrían  ocasionar  a  la  larga  que  todo  acabe  siendo  muy 
caótico. 

-  No  tiene  perspectivas  de  avanzar  tecnológicamente.  Tal  y  como  se  comentó  en 
el  anterior  capítulo,  los  dispositivos  de  conmutación  serán  parte  fundamental  del 
sistema  de  protección  de  acceso  a  redes.  Es  parte  estratégica  en  esto  la  implementación 
basada  en  VLAN.  El  diseño  descrito  no  ofrece  posibilidades  para  esa  evolución  que 
permita  la  protección  de  la  red. 

-  Poca  respuesta  frente  a  fallos.  Las  arquitecturas  de  electrónica  de  red  basadas 
en  VLAN  presentan  por  lo  general  sistemas  de  redundancia  donde  !a  gestión  puede 
ser  compartida  y  transmitida  a  través  de  la  diferente  electrónica  de  red  existente. 
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Un  tallo  podría  repercutir  en  un  segmento  pero  no  por  ello  tener  que  afectar  a  toda 
la  red.  Sin  embargo  en  el  sistema  anterionnente  descrito  existen  múltiples  puntos 
de  fallo  que  perjudicarían  seriamente  el  funcionamiento  de  la  red  ante  un  problema 
potencial. 


La  gran  baza  de  la  tecnología  VLAN  es  sobre  todo  la  flexibilidad  que  proporciona  y  la 
capacidad  para  una  gestión  eficaz  de  toda  la  configuración  desde  un  único  punto.  Hay 
que  tener  en  cuenta  que  cuanto  mayor  sea  una  red,  mayor  será  la  complejidad  de  su 
administración.  La  incorporación  de  nuevos  dispositivos  de  conmutación  implicaría  una 
problemática  sin  una  gestión  eficiente  del  entorno. 

Para  hacer  esto,  los  sistemas  de  integración  VLAN  soportan  mecanismos  que  permiten 
a  múltiples  redes  compartir  de  forma  transparente  el  mismo  medio  físico.  Esto  implica 
que  una  VLAN  con  ID  2  podrá  ser  compartida  entre  múltiples  dispositivos  conectados 
a  la  red.  De  esta  forma  lodo  el  conjunto  operará  como  si  fuera  uno  solo.  Para  establecer 
esta  fúncionaiídad  es  requerido  que  la  información  pueda  transitar  entre  los  dispositivos 
dentro  de  una  misma  VLAN  {Trunktng).  Para  ello  existen  diferentes  mecanismos,  siendo  la 
implementación  802ríQ  el  estándar  para  lograr  este  fin. 

El  sistema  802 JQ  fue  definido  a  través  de  la  RFC  3069.  Establece  el  mecanismo  por  el 
cual  equipos  que  se  encuentren  en  el  mismo  segmento  físico  de  una  red  conmutada,  pero 
separados  por  dominios  de  colisión  virtuales,  pueden  convivir  en  un  mismo  espacio  lPv4, 
compartiendo  además  la  misma  puerta  de  enlace.  Este  mecanismo  consiste  en  etiquetar  las 
tramas  de  tal  forma  que  puedan  ser  conocidos  y  encaminados  por  todos  los  dispositivos  de 
conmutación  de  la  infraestructura  hacía  las  VLAN  que  corresponda  por  etiquetado.  Esta 
VLAN  pudiera  estar  en  un  solo  dispositivo  o  repartido  entre  varios. 


Switcht 

Switciifeoii figure  terminal 

Enter  conf igiiration.  coinmaJida,  one  per  line.  End  wdth  CTKTL/Z. 
SwicdiíconfigJ tinterface  faetEthernet  0/2 
Switchíconfig-if ) fencapgulacion  dotlq  101 

Fíg.  9.1.-  ImplemenLadón  de  802.  IQ 


Aunque  el  sistema  de  etiquetado  es  el  definido  dentro  del  estándar,  existen  en  el  mercado 
dispositivos  que  no  admiten  802.  IQ,  por  lo  tanto  también  se  definió  la  posibilidad  de 
establecer  una  comunicación  entre  una  VLAN  etiquetada  y  otra  que  no  lo  soporta:  VLAN 
nativa.  La  VLAN  nativa  permite  a  un  puerto  8.2.  IQ  convivir  con  un  puerto  de  tipo  estándar 
802.3  recibiendo  y  enviando  tráfico  que  no  se  encuentra  etiquetado. 
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Switch# configure  rerininal 

Snter  configurar ion  oommand^j  one  per  line^  End  wirh  CNTL/Z. 
Svitch^configí  pintar  face  faatSthemet  0/1 
Switch.í conf ig-if )  tawitchpQrt  trunk  nativa  vían  Z 
Switchí  config-if ) 

%SYS-5-COÍIFIG_I :  Configured  from  consolé  by  Ganaole 
Svitch#! 

Fig.  9,2,-  Configuración  puerto  en  VLAN  nativa. 


Los  puertos  configurados  como  VLAN  nativo  deben  encontrarse  bien  controlados  para 
evitar  que  el  tráfico  sensible  se  filtre  a  través  de  los  mismos.  También  es  muy  importante 
que  la  VLAN  nativa  no  se  encuentre  definida  con  el  ID  1 .  Esto  es  debido  a  que  esta  VLAN 
es  la  considerada  de  gestión  y  sobre  la  que  se  administran  los  dispositivos.  Si  un  equipo 
estuviera  conectado  a  un  dispositivo  o  puerto  de  red  VLAN  nativa  tendría  acceso  a  la  capa 
de  administración  de  los  dispositivos. 

Un  potencial  atacante  podría  aprovechar  malas  configuraciones  de  una  infraestmetura  de 
red  para  intentar  saltarse  la  seguridad  de  una  infraestmetura  de  VLAN.  El  salto  de  VLAN 
se  puede  realizar  a  través  de  dos  técnicas  diferentes: 

-  Switch  Spoofing. 

“  Double  Taggíng. 


El  primero  supone  aprovechar  una  mala  configuración  de  los  puertos  tipo  trunk.  Este 
elemento  importante  en  la  configuración  de  VLAN,  es  utilizado  para  pasar  la  información 
de  VLAN  entre  dispositivos.  Un  puerto  de  tipo  trunk,  podría  pertenecer  a  todas  las  VLAN 
existentes. 


Svitch  ( CDiifigJ  t 

Switch  í  config)  tinrer face  faatEthezinet  0/1 
Switch  ícanfig-if)  íawitchport  inüd.e  trunk 
Switch  íconfig-if)  # 

Fig.  9.3.-  Configiiración  de  puerto  en  modotnink. 


Existe  la  posibilidad  de  hacer  uso  de  la  configuración  de  aido-trunking  (Dinamics  Trunkíng 
Protocol  en  Cisco)  para  realizar  una  suplantación  de  Switch,  Este  modo  utilizado  en  algunos 
entornos,  implica  que  un  puerto  se  encuentra  configurado  en  modo  pasivo  esperando  que 
otro  extremo  dentro  de  !a  capa  de  enlace  solicite  al  puerto  pasar  a  modo  troncal.  De  esta 
forma  se  automatiza  la  configuración  de  los  puertos  troncales  para  VLAN  802.  IQ  u  otros 
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como  ISL  (Ínter-Swíích  Link).  Aunque  esta  funcionalidad  permite  de  forma  rápida  poder 
conectar  dispositivos  Switch  a  una  infraestructura  haciéndolo  pertenecer  a  la  misma  y 
permitiendo  el  enlace  a  las  redes  VLAN  presenta  ciertos  riesgos  de  seguridad. 

Si  un  equipo  se  encuentra  conectado  a  un  puerto  en  modo  auto-tnmking^  podría  hacerse 
pasar  por  un  conmutador^  o  bien  conectar  directamente  a  un  Switch,  que  pueda  negociar 
la  conectividad  tmnk,  con  el  otro  extremo.  De  esta  forma  el  atacante  podria  pertenecer 
a  cualquier  VLAN  existente  en  la  infraestructura  La  técnica  de  ataque  VLAN  Hopping 
aprovecha  una  mala  configuración  para  dialogar  a  través  de  uu  puerto  configurado  en  modo 
auío-trunking.  Para  ello  el  Switch  malicioso  deberia  estar  configurado  para  negociar  con 
un  puerto  de  autoconfiguración. 


Switiízhf CQnf  terin 

Ent^er  conf cQmmaziUs,  one  per  l±ne  _  End  with.  CNTL/Z_ 
Switch (cQnfig 3 tlnt  f aatEtheimet  □/! 

Switch (config-^if  3  #3Wltch.pQrt  mode  dynamic  deairahle 
Switchí config-if 3  f 

Fig.  9.4.-  Configuración  de  un  puerto  para  negociación  del  enlace  troncal 


Lo  único  que  faltaría  seria  renviar  el  tráfico  del  puerto  del  Switch  controlado  por  el  atacante 
a  su  sistema.  También  es  factible  realizar  el  ataque  a  través  de  la  aplicación  Yersinia.  Con 
ella  puede  realizarse  la  configuración  dcl  sistema  con  DTP  para  intentar  negociar  con  el 
puerto  del  Switch  donde  está  conectado  el  sistema. 


lUttRcfeaísaejíi  _ 


CDP  óHCf*  saaig  ^  i 


iMdohteMCí  Ccahit  lA&tSieeft 


wp  0KD*  mip  mixi  dtp  HSftp  ist  vtp 
Choese  attack 
Desen  ption 

O  sendífig  DTP  pacfcet  <3; 

O  [enaúmg  jy  I 


55- _  J  fe2:0e-6C:( 

Vtefsíon  [ai]  NetghbofiD  jicTCEewsisJ  status  ®  ^v; 


Fíg.  9.5,-  Preparación  del  ataque  de  negociación  Ü  IR 
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Una  vez  que  la  configuración  ha  sido  efectuada  a  través  de  la  aplicación,  se  podrá  lanzar  el 
ataque  para  intentar  negociar  con  el  dispositivo  conectado* 


%  Yersínía  0.7.1 

riíí'  AcSfom  Ooíaons 


•  ^  BIP  [  hsRP  ISL  STP  vp  ■rtastría 

[l^jíighbcHS  , 


Status 


Qpmatn  ^  liifffaoff  ICounÉ 


0G7C£ft46DS&$  Ü3  ACC£SS©ESfRAtll£ 


ettvO  0  2 


T  V 

fteiri 

Wie  3^ 

S<Hjn:e  MAC 

0C:7CES:4|i 

nation  MAC 

01:00  oeq  i 

Versión 

01  f 

Neighborio 

0C7CES46d 

Sl^us 

03  f;' 

Type 

2! Í2 

Sourc« MAC  :9C:7C:E8:46:&5:95|  DestJfWtkm  MAC 

A  í — ■  ■ 

i  versííMi  jBi|  Wíi^ghíMMD  |Bi:íCEa4&ü59y  staftijs 


Íei;eO;9C.< 


^3 


Fig.  9.6.-  Lanzando  el  ataque  con  yt^rsinia. 


Si  el  ataque  es  efectivo,  puede  combinarse  con  más  ataques  como  802*  1 Q  Poisoning, 
para  realizar  un  envenenamiento  clásico  aprovechando  la  técnica  anterior. 


Fig.  9.7.-  Ataque  de  802. 1 Q  Arp  Foisoning. 
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Para  evitar  este  ataque  lo  mejor  sería  no  configurar  el  modo  de  auto  negociación  en  aquellos 
puertos  donde  vayan  a  estar  conectados  equipos.  Solo  habilitado  para  puertos  donde  puedan 
estar  conectados  otros  conmutadores. 

El  ataque  Double  Tagging,  consiste  en  realizar  un  doble  etiquetamiento  para  el  tráfico 
generado  por  un  sistema.  Se  encapsula  tráfico  802.Q  dirigido  a  un  equipo  en  otra  VEAN, 
en  una  trama  802 JQ  de  la  VLAN  en  la  que  se  eneuentra  el  atacante.  El  Switch  que  recibe 
la  trama  realiza  el  desencapsulado  nativo  de  un  solo  nivel,  remitiendo  el  tráfico  a  través  de 
la  otra  VLAN.  Aunque  el  ataque  puede  ser  efectivo  hay  que  tener  en  cuenta  que  el  tráfico 
se  puede  generar  en  una  sola  dirección.  Si  ñiera  necesario  una  respuesta  el  sistema  destino 
no  devolvería  respuesta  puesto  que  las  suyas  no  irían  doblemente  etiquetadas.  Este  ataque 
que  puede  realizarse  con  Yerslnia^  es  empleado  habitual  mente  para  ataques  de  denegación 
de  ser\ácio. 


Fig.  9.S,-  xVtaque  de  doble  etiquetamiento. 

El  sistema  de  802.  IQ  proporciona  un  estándar  frente  a  las  implementaciones  propietarias 
que  como  Cisco  que  con  su  VTP  (VLAN  Trunk  Protocol)  harían  factible  también  esa 
posibilidad.  Este  protocolo  pennite  transmitir  la  configuración  de  las  VLAN  a  través  de  los 
dispositivos,  de  tal  forma  que  cada  dispositivo  presenta  un  comportamiento  caracteristico 
{cliente,  servidor  o  transparente). 


Sw± t  ch ( conf ig ) #vtp  ? 

domain  Set:  the  naine  of  rhe  VTP  ediEdniscretive  damain. 
mode  Configure  VTP  de  vi  ce  Ei£Hde 

pa.3  3wDrd  Set  the  pasaKord  for  the  VTP  edminiatrative  domain 
veraiozi  Set  the  admi  ne  t  r  at  i  ve  domain  to  VTP  versión 


Fig.  9.9  -  Coníigumción  VTP. 
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En  función  de  la  configuración  de  la  infraestructura  un  atacante  podría  intentar  falsear  ¡a 
información  de  las  VLAN  existentes,  agregando,  cambiando  o  eliminando  configuraciones. 
Para  un  uso  seguro  de  VTP  se  admite  y  será  necesaria  la  implementación  de  password  para 
impedir  obtener  información  falseada,  sin  embargo  hay  que  tener  en  cuenta  que  para  su 
cifrado  se  utiliza  un  hash  de  tipo  MD5.  Si  la  clave  no  es  muy  robusta  pudiera  ser  atacada 
para  intervenir  en  el  entorno. 


Fig,  9. 10.-  AUL|ues  sobre  VTR 


9.2.-  Salto  a  redes  de  VoIP 

Las  redes  VolP  se  han  hecho  a  día  de  hoy  muy  populares  en  las  organizaciones.  Suponen 
un  ahorro  de  costes  al  ser  integrados  en  la  infraestructura  de  comunicaciones  y  sustituir  a  la 
telefonía  tradicional.  Adicionalmente  puede  también  integrarse  con  otros  servicios  como  el 
de  correo  electrónico.  La  información  de  dicha  red,  puede  ser  tan  importante  e  interesante 
para  un  atacante  como  la  de  las  redes  de  datos. 

En  lógica  general  dicha  red  debe  estar  separada  de  la  red  de  datos.  Sin  embargo  en  algunas 
de  las  implementaciones  de  configuración  de  redes  VolP,  para  realizar  un  ahorro  de  costes 
tanto  en  puertos  de  conexión  como  de  electrónica  de  red,  una  misma  conexión  puede  ser 
utilizada  concurrentemente  para  la  conexión  del  teléfono  IP  de  voz  sobre  IP  y  un  equipo 
para  red  de  datos.  El  equipo  se  conecta  al  teléfono  vía  Ethernet  y  este  renviará  los  paquetes 
recibidos  y  los  correspondientes  al  propio  dispositivo  al  Switch  con  el  que  estará  conectado. 
El  teléfono  funciona  en  este  modo  como  repetidor.  Si  esta  es  la  circunstancia  entonces 
¿cómo  se  hace  la  división  de  tráfico  de  voz  y  datos?  Simplemente  el  puerto  a!  que  se 
conecta  el  teléfono  se  le  asignan  dos  VLAN,  una  para  cada  tipo  de  conexión. 
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Switchtconfigure  teooiíial 

£nt€fr  configuración  commaníia ,  one  per  line .  End  wich  CNTL/Z. 

Switch íconfig)  tinte rf ace  fagtetliemet  0/1 

Síjitch^config-if)  tswitchport  mode  aoceaa 

Switch  i|  config-if )  fawitchport  acceae  vían  10 

Switch  (co.nfig-if )  tawitchport  voic-e  vían  20 

Switch<gQnfíg— if J  f 

Fig.  9.1  L-  Configuración  de  puerto  para  trafico  de  voz  y  datos. 


El  teléfono  de  voz  sobre  IP,  deberá  ser  configurado  para  utilizar  como  etiqueta  la  red  VEAN 
correspondiente,  la  20  en  la  anterior  imagen.  Para  poder  interceptar  conversaciones  que  se 
puedan  estar  produciendo  en  la  red  de  voz  sobre  IP,  será  necesario  realizar  la  suplantación 
del  dispositivo.  Para  ello  lo  primero  será  interceptar  el  tráfico  de  identificación  del  teléfono. 
Ahí  se  envían  los  parámetros  del  mismo  e  identifica  a  su  vez  los  parámetros  de  la  VEAN 
en  la  que  se  encuentra  el  mismo.  Dicha  identificación  puede  ser  realizada  simplemente  con 
un  sniffer  configurado  en  el  equipo  atacante  e  iniciando  el  teléfono.  Una  vez  que  los  datos 
del  teléfono  han  sido  obtenidos  se  procederá  a  retirar  el  mismo  y  a  realizar  el  proceso  de 
suplantación  y  salto  a  la  red  de  VoIP  con  el  equipo  a  través  de  la  aplicación  Voiphopper. 

Esta  creará  un  adaptador  virtual  con  los  datos  necesarios  para  que  desde  la  misma  se 
pueda  enviar  datos  a  través  de  la  red  VLan  de  VolP,  en  esta  circunstancia  la  VEAN  20.  La 
siguiente  imagen  muestra  el  resultado  del  ataque,  teniendo  como  consecuencia  la  detección 
de  la  VLAN  20  y  creando  un  adaptador  virtual  eth0.20,  que  podrá  ser  utilizado  para  los 
ataques  sobre  la  red  de  voz. 


pT  ^  X 

Archivo  L:íitar  lenrir?! 

üOTíJvdS’: i voiphopper  -i  ethO  -c  1  -E  ' =  -P  "Port  2"  -Z  Hast  -L 
Cibto  IP  Phuiie  ^97^'  'S  ^SCP70, 8^5-20'  U  L 
VflTP  Hoppf^r  1  Rtinnlng  1n  fFjr*  fipoof  mác 
'jendinq  IST  CDH  Í3poo*ed  packet  on  etho  lí/lth  CDP  packet  líatB: 

Device  ID  i  SIPOO00CFEF9D62 ;  Port  ID,  Port  2;  Sottvíare;  SCP79. 8-5^20 
Pld.''u!m:  Civeu  IP  Phoiie  ^970;  CapdhJ™ íutílcf»-. s  1 
mdc’  rrjp  ei-^  i?t  soivt  rnp  pricJirt  of  ? 

Lap^ured  ílll  üoz.j,  cdp  Packet  of  4b&  bytes 
Piscovered  voiP  vlaW:  2ú 

Sending  2nd  CDP  Spooted  packet  on  ethD  ^fith  CDP  packet  jata: 

Devite  ID:  SIPOS00CFEF9D62  :  Pui  L  ID:  Pui  L  2;  9-5-20 

ri-form :  ri  tp  Phanc  ;  fr'iptih  1 1  -i  túc'';  1  ;  itinl  r>; -  l 

fiade  LPF  packeT  I2l  bvres  -  sent  CPP  packít  of  _2l  byte;5 
Added  VLAM  20  to  Iiitertace  ethS 
Curiep,  HAC:  OO; le;et :59:29:71 
voTP  Hopprr  vjI"  ’  orp  rind  Thrn  mr 

Aiiempiinq  dhcp  reques”  neuí  interface  erhü/Zü  I 

'ooií^vas-:"^  I 


Fig.  9.12.-  Ataque  vori  Voiphopper. 
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El  nuevo  adaptador  creado  podrá  ser  utilizado  con  posterioridad  para  los  ataques 
convencionales  de  ARP  Poisonlng  pero  sobre  la  red  de  voz.  Aunque  existen  algunas 
diferencias  significativas  en  los  protocolos  de  ía  capa  de  aplicación,  lo  concerniente  a  la 
capa  de  enlace  y  de  red  comparte  funcionalidad  con  las  redes  de  datos  clásicas. 

Los  ataques  de  hombre  en  medio  pueden  realizarse  igualmente  en  una  red  de  VoIP.  Salvo  que 
las  tramas  correspondientes  a  las  conversaciones  y  conexiones  a  centralitas,  vayan  cifradas, 
el  audio  podría,  una  vez  haya  sido  interceptada  una  comunicación,  ser  decodificado  por  el 
atacante.  Además  de  los  mecanismos  propios  del  cifrado  de  VoíP  y  que  pueda  proporcionar 
el  fabricante,  se  podrían  aplicar  los  mismos  mecanismos  que  se  aplican  para  proteger  una 
red  de  datos,  por  ejemplo  el  uso  de  DIICP  Snooplng. 
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Las  redes  de  datos  IP  hace  mucho  tiempo  que  gobiernan  nuestras  sociedades. 
Empresas,  gobiernos  y  sistemas  de  interacción  social  se  basan  en  redes 
TCP/IP.  Sin  embargo,  estas  redes  tienen  vulnerabilidades  que  pueden  ser 
aprovechadas  por  un  atacante  para  robar  contraseñas,  capturar  conversacio¬ 
nes  de  voz,  mensajes  de  correo  electrónico  o  información  transmitida  desde 
servidores.  En  este  libro  se  analizan  ios  ataques  más  comunes  en  redes  de 
datos  lPv4  e  XPv6. 

En  este  texto  encontrarás  cómo  funcionan  los  ataques  de  man  in  the  midd/e 
en  redes  lPv4  o  IPv6,  cómo  por  medio  de  estos  ataques  se  puede  crackear  una 
conexión  VPN  PPTP,  robar  la  conexión  de  un  usuario  al  Active  Directory  o 
cómo  suplantar  identificadores  en  aplicaciones  para  conseguir  perpetrar  una 
intrusión. 

En  los  diferentes  capítulos  que  componen  el  libro  encontrarás  descrito  el  fun¬ 
cionamiento  de  las  técnicas  ARP-Spoofing,  Neighbor  Spoofing  en  lPv6,  el 
ataque  SLAAC  o  los  ataques  de  DHCP  basados  en  servidores  Rogue  o  en 
paquetes  DHCP  ACK  por  medio  de  herramientas. 
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